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]

On Tue, 05 Aug 2008 10:54:38 -0700, Tom P. <pa***********@ 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]

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]

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 )]

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.]

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.]

On Aug 5, 1:12*pm, michel.desang.. [e-mail] 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]

On Tue, 05 Aug 2008 11:12:01 -0700, <mi************ **@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.]

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]

On Tue, 05 Aug 2008 11:23:04 -0700, Tom P. <pa***********@ 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