How expensive is brush creation?

[Tom P.]

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

Thanks for the info.

Tom P.

[Peter Duniho]

Re: How expensive is brush creation?

On Tue, 05 Aug 2008 10:54:38 -0700, Tom P. <padilla.henry@ gmail.comwrote:

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

What's the speed difference when you measure your two proposed
implementations ? What performance problem are you trying to solve?

If the answers to those questions are "I haven't measured" and/or "no
particular performance problem", then you are premature in worrying about
the expense of creating a brush.

Pete

[michel.desangles@gmail.com]

Re: How expensive is brush creation?

On 5 août, 19:54, "Tom P." <padilla.he...@ gmail.comwrote:

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?
>
Thanks for the info.
>
Tom P.

It is VERY expensive, not because of the brushes themselves, but
because you're feeding the Garbage Collector with all those brushes on
every Paint event.

You'd be better off using the system Brushes, which are static. Use:

Brushes.Black

instead of:

Brush b = new SolidBrush(Colo r.Black)

If you frequently use the same colors that are outside the 216
predefined ones, you can do this (in a static class, for instance):

private static Brush orangeyBrush;

public static Brush Orangey
{
get
{
if (orangeyBrush == null)
return (orangeyBrush = new
SolidBrush(Colo r.FromArgb(223, 156,0)));
}
}

This mimics what the framework does internally (lazy initialization) .

Michel

[michel.desangles@gmail.com]

Re: How expensive is brush creation?

On 5 août, 20:01, "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Tue, 05 Aug 2008 10:54:38 -0700, Tom P. <padilla.he...@ gmail.comwrote:

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

>
What's the speed difference when you measure your two proposed  
implementations ?  What performance problem are you trying to solve?
>
If the answers to those questions are "I haven't measured" and/or "no  
particular performance problem", then you are premature in worrying about 
the expense of creating a brush.
>
Pete

Yes, I assumed "paint" meant "paint event". If it is "paint" as in
"image" or "picturebox " for instance, Pete's right, the improvement
might hamper readability for a negligible gain.

Michel

[Ignacio Machin ( .NET/ C# MVP )]

Re: How expensive is brush creation?

On Aug 5, 1:54 pm, "Tom P." <padilla.he...@ gmail.comwrote:

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?
>
Thanks for the info.
>
Tom P.

Hi,

I do not know for sure in managed world but in unmanaged a Brush is a
system ersource, so you have to be careful with it.
Why you need that many?

[Tom P.]

Re: How expensive is brush creation?

On Aug 5, 1:01 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Tue, 05 Aug 2008 10:54:38 -0700, Tom P. <padilla.he...@ gmail.comwrote:

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

>
What's the speed difference when you measure your two proposed  
implementations ?  What performance problem are you trying to solve?
>
If the answers to those questions are "I haven't measured" and/or "no  
particular performance problem", then you are premature in worrying about 
the expense of creating a brush.
>
Pete

Nothing I've measured but the effort of redesigning my framework to
accommodate static brushes is no small feat. I am writing a file
manager and I custom paint each listview subitem (using
OnDrawSubItem). I allow custom colors and lineargradient brushes for
each subitem (name, size, and date). I have taken count and I'm
creating over 1000 brushes just to pull up a directory listing of the
root of my dev PC. Now I'm thinking about adding a color option for
Directories vs. Files (and maybe even readonly etc.) and so I'm forced
to wonder if the painting could get expensive.

Tom P.

[Tom P.]

Re: How expensive is brush creation?

On Aug 5, 1:12 pm, michel.desang.. .@gmail.com wrote:

On 5 août, 19:54, "Tom P." <padilla.he...@ gmail.comwrote:
>

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

>

Thanks for the info.

>

Tom P.

>
It is VERY expensive, not because of the brushes themselves, but
because you're feeding the Garbage Collector with all those brushes on
every Paint event.
>
You'd be better off using the system Brushes, which are static. Use:
>
Brushes.Black
>
instead of:
>
Brush b = new SolidBrush(Colo r.Black)
>
If you frequently use the same colors that are outside the 216
predefined ones, you can do this (in a static class, for instance):
>
private static Brush orangeyBrush;
>
public static Brush Orangey
{
  get
  {
    if (orangeyBrush == null)
       return (orangeyBrush = new
SolidBrush(Colo r.FromArgb(223, 156,0)));
   }
>
}
>
This mimics what the framework does internally (lazy initialization) .
>
Michel

I appreciate the help but I've got custom colors and lineargradient
brushes just littering this thing. As well as mouseover brushes and
now I'm kicking around the idea of Directory vs. File brushes and
maybe System or ReadOnly brushes. I've got to find a way to make them
permanent but I've also got the issue of creating the brush within the
correct bounds (what if the user changes the size of the column, I
need to resize the brush accordingly).

I'm gonna have to think this one through. Thanks.

Tom P.

[Peter Duniho]

Re: How expensive is brush creation?

On Tue, 05 Aug 2008 11:12:01 -0700, <michel.desangl es@gmail.comwro te:

It is VERY expensive, not because of the brushes themselves, but
because you're feeding the Garbage Collector with all those brushes on
every Paint event.

The GC design is optimized to handle repeated allocation and discarding of
short-lived objects. GC is not an issue here at all, though disposal of
brushes _theoretically_ might be. I doubt most code would see any issue.

You'd be better off using the system Brushes, which are static. Use:
>
Brushes.Black

Yes, very true. If one of the pre-defined brushes is adequate, using that
is much better than creating and disposing one.

Pete

[Tom P.]

Re: How expensive is brush creation?

On Aug 5, 1:22 pm, "Ignacio Machin ( .NET/ C# MVP )"
<ignacio.mac... @gmail.comwrote :

On Aug 5, 1:54 pm, "Tom P." <padilla.he...@ gmail.comwrote:
>

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

>

Thanks for the info.

>

Tom P.

>
Hi,
>
I do not know for sure in managed world but in unmanaged a Brush is a
system ersource, so you have to be careful with it.
Why you need that many?

You bring up a very good point: what the heck am I doing? I made the
incorrect assumption that this would be a "yes/No" question and I'd be
done with it. My apologies all around.

I am making a file manager that paints each item in custom colors and
gradients at custom angles (lineargradient brushes). The mouseover
event will repaint the item with a custom mouseover brush. With each
subitem getting it's own paint event (OnDrawSubItem) this results in
~1,000 brushes for a simple 10 directory root drive.

Now I'm contemplating the addition of Directory Vs. File brushes and
even System vs. ReadOnly brushes. Hence the question.

Tom P.

[Peter Duniho]

Re: How expensive is brush creation?

On Tue, 05 Aug 2008 11:23:04 -0700, Tom P. <padilla.henry@ gmail.comwrote:

[...]

>What's the speed difference when you measure your two proposed  
>implementation s?  What performance problem are you trying to solve?
>>

[...]
>
Nothing I've measured but the effort of redesigning my framework to
accommodate static brushes is no small feat.

All the more reason to not do that unless you know for sure you have to.

I am writing a file
manager and I custom paint each listview subitem (using
OnDrawSubItem). I allow custom colors and lineargradient brushes for
each subitem (name, size, and date). I have taken count and I'm
creating over 1000 brushes just to pull up a directory listing of the
root of my dev PC.

1000 brushes? To display just one directory?

All due respect, I doubt the human brain is capable of comprehending a UI
presentation with that much variety in it.

Now I'm thinking about adding a color option for
Directories vs. Files (and maybe even readonly etc.) and so I'm forced
to wonder if the painting could get expensive.

Well, it _could_. Especially if just one directory causes you to create
1000 different brushes. But as long as things are performing adequately,
I don't think you should worry about it. Even if you do run into
performance issues, you might reconsider whether it's really necessary to
use so many different brushes. That is probably a better solution than
trying to cache thousands of brushes (as Ignacio points out, the unmanaged
resource in a brush is relatively scarce and so shouldn't be held on to
for long periods of time, especially in such large numbers).

Pete

[Tom P.]

Re: How expensive is brush creation?

On Aug 5, 1:41 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Tue, 05 Aug 2008 11:23:04 -0700, Tom P. <padilla.he...@ gmail.comwrote:

[...]

What's the speed difference when you measure your two proposed  
implementations ?  What performance problem are you trying to solve?

>

[...]

>

Nothing I've measured but the effort of redesigning my framework to
accommodate static brushes is no small feat.

>
All the more reason to not do that unless you know for sure you have to.
>

I am writing a file
manager and I custom paint each listview subitem (using
OnDrawSubItem). I allow custom colors and lineargradient brushes for
each subitem (name, size, and date). I have taken count and I'm
creating over 1000 brushes just to pull up a directory listing of the
root of my dev PC.

>
1000 brushes?  To display just one directory?
>
All due respect, I doubt the human brain is capable of comprehending a UI 
presentation with that much variety in it.
>

Now I'm thinking about adding a color option for
Directories vs. Files (and maybe even readonly etc.) and so I'm forced
to wonder if the painting could get expensive.

>
Well, it _could_.  Especially if just one directory causes you to create  
1000 different brushes.  But as long as things are performing adequately,  
I don't think you should worry about it.  Even if you do run into  
performance issues, you might reconsider whether it's really necessary to 
use so many different brushes.  That is probably a better solution than 
trying to cache thousands of brushes (as Ignacio points out, the unmanaged  
resource in a brush is relatively scarce and so shouldn't be held on to  
for long periods of time, especially in such large numbers).
>
Pete

I'm sorry, I must have misspoke. I don't create a thousand different
brushes, I only create about 6 or 9 different brushes... hundreds of
times. Each Item has a NameBrush, a SizeBrush, and a DateBrush for
each circumstance they could be in (unselected, selected, mouseover,
etc.). But they are created over and over and over again for each item
in the filelist. For example, everytime I pass the mouse pointer over
an item I must create three of the unselected brushes to "clear" the
old items look, then I must create three new brushes to paint the new
items mouseover look. That's 6 brushes just to move the mouse from one
item to the next.

Tom P.

[Peter Duniho]

Re: How expensive is brush creation?

On Tue, 05 Aug 2008 11:27:45 -0700, Tom P. <padilla.henry@ gmail.comwrote:

I appreciate the help but I've got custom colors and lineargradient
brushes just littering this thing. As well as mouseover brushes and
now I'm kicking around the idea of Directory vs. File brushes and
maybe System or ReadOnly brushes. I've got to find a way to make them
permanent but I've also got the issue of creating the brush within the
correct bounds (what if the user changes the size of the column, I
need to resize the brush accordingly).

One possible "in-between" solution you might consider is to keep just one
static brush instance, updated as necessary. Maintain some sort of
description of the brush so you know what's actually in that brush (which
you'd have to do with any static brush caching anyway).

If an item has multiple elements, each that might be drawn with its own
brush, you could increase the number of static brushes to the maximum
number of brushes any one element might use.

That way, if several items with the same visual appearance are drawn in
immediate succession, you can just use the brush(es) from the last drawing
operation rather than recreating the brushes anew each time. At the same
time, it avoids you having to implement a full-fledged brush caching
system (the code for which would be much more complicated, never mind the
system resource cost of keeping thousands of brushes or more around
full-time).

Pete

[michel.desangles@gmail.com]

Re: How expensive is brush creation?

On 5 août, 20:27, "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Tue, 05 Aug 2008 11:12:01 -0700, <michel.desang. ..@gmail.comwro te:

It is VERY expensive, not because of the brushes themselves, but
because you're feeding the Garbage Collector with all those brushes on
every Paint event.

>
The GC design is optimized to handle repeated allocation and discarding of  
short-lived objects.  GC is not an issue here at all, though disposal of  
brushes _theoretically_ might be.  I doubt most code would see any issue.
>

You'd be better off using the system Brushes, which are static. Use:

>

Brushes.Black

>
Yes, very true.  If one of the pre-defined brushes is adequate, using that  
is much better than creating and disposing one.
>
Pete

Still, this :
for (int i = 0; i < 1000000; i++)
{
Brush b = new SolidBrush(Colo r.Blue);
}
...in release mode takes something like 160 Mb of RAM and lasts
approximately one second. Even optimized, it has to put some pressure
on the GC. But again, when reading Tom's description I incorrectly
assumed "lots" meant "millions of brushes" (I'm working on a rather
complex real-time video thingy atm where every cycle saved is
crucial). You're absolutely right it amounts to nothing in Tom's case.

Michel

[Ignacio Machin ( .NET/ C# MVP )]

Re: How expensive is brush creation?

On Aug 5, 2:27 pm, "Tom P." <padilla.he...@ gmail.comwrote:

On Aug 5, 1:12 pm, michel.desang.. .@gmail.com wrote:
>
>
>

On 5 août, 19:54, "Tom P." <padilla.he...@ gmail.comwrote:

>

I am doing quite a bit of custom painting and it means I have to
create a lot of brushes (think one for every file system object in a
directory) per paint. How expensive is this? Should I find a way to
create the brushes once, store them in an member variable, and use
them when I need them? Or is creating brushes a throw-away process
that doesn't take a lot of work?

>

Thanks for the info.

>

Tom P.

>

It is VERY expensive, not because of the brushes themselves, but
because you're feeding the Garbage Collector with all those brushes on
every Paint event.

>

You'd be better off using the system Brushes, which are static. Use:

>

Brushes.Black

>

instead of:

>

Brush b = new SolidBrush(Colo r.Black)

>

If you frequently use the same colors that are outside the 216
predefined ones, you can do this (in a static class, for instance):

>

private static Brush orangeyBrush;

>

public static Brush Orangey
{
get
{
if (orangeyBrush == null)
return (orangeyBrush = new
SolidBrush(Colo r.FromArgb(223, 156,0)));
}

>

}

>

This mimics what the framework does internally (lazy initialization) .

>

Michel

>
I appreciate the help but I've got custom colors and lineargradient
brushes just littering this thing. As well as mouseover brushes and
now I'm kicking around the idea of Directory vs. File brushes and
maybe System or ReadOnly brushes. I've got to find a way to make them
permanent but I've also got the issue of creating the brush within the
correct bounds (what if the user changes the size of the column, I
need to resize the brush accordingly).
>
I'm gonna have to think this one through. Thanks.
>
Tom P.

Ok, that's fine
but why you need to create XXXXX number of DIFFERENT brushes? I would
assume that you need one per type at most.

[Peter Duniho]

Re: How expensive is brush creation?

On Tue, 05 Aug 2008 11:56:24 -0700, Ignacio Machin ( .NET/ C# MVP )
<ignacio.machin @gmail.comwrote :

but why you need to create XXXXX number of DIFFERENT brushes? I would
assume that you need one per type at most.

I assume it's because he's doing the drawing in a handler that gets called
once per item, so each item has no knowledge of other items that got drawn.

If one was doing the whole UI at once in a single Paint handler, it would
be easy to batch up all the brushes (or even to sort the drawing by brush,
which would be the best performance). But if he draws 1000 items, and is
creating and disposing the brushes in the item-drawing handler (which is
not fundamentally a bad design at all), then that's 1000 different brushes.

I didn't pick up on that initially, but based on his other replies, that
seems like what's going on.

Pete