Re: repainting own panel-component

From: J French (erewhon_at_nowhere.com)
Date: 03/29/04 

Date: Mon, 29 Mar 2004 08:09:57 +0000 (UTC)

On Sun, 28 Mar 2004 14:30:20 -0600, Rob Kennedy <me3@privacy.net>
wrote:

>J French wrote:
>>> I figure the slowdown might be from however Dirk is determining that
>>> three seconds have passed and that the control needs to be repainted. I
>>> hope he's using a timer and not a loop.
>>
>> I did not see anything about 3 Seconds
>
>Oh, nevermind. Neither did I, apparently. I saw something about the
>colors changing every three pixels, but must have stopped reading before
>I reached "pixels." I was imagining some color-cycling.

That the trouble with my NG reader
.... the print is so small that I misread things
.... larger print makes the reader unuseable

>Unfortunately, now that I know the display isn't changing dynamically, I
>don't have anything to blame for the slowdown anymore.

I reckon it is multiple recreation of the background canvas

>
>> - actually I would not have any 'timing' or delay at all
>> - from watching Paint Events, they seem to only happen when necessary
>>
>> Ah! I see what you mean
>
>Well, that makes one of us!

It clicked that you suspected that the OP actually had some delay
stuff to prevent multiple regeneration of the b/g canvas during
resizing

>
>> You are saying that the Resize Event could occur hundreds of times
>> - but when something gotta be painted, it gotta be painted
>> - I think the 'oversize' background and copying large chunks will
>> eradicate that problem
>> - but you've made me think that the resize event is not necessarily
>> the best place to build the background canvas
>
>I still think that is the best place. However, there are ways to reduce
>the load when the window is being resized. When a resize operation
>begins, Windows sends a wm_Sizing message. (This might be difficult,
>depending on whether all the controls get that message or only the
>top-level window.) When the window is in "sizing" mode, you could turn
>off generation of new bitmaps and just continue painting the old size.
>When the window receives a wm_Size message, that means the resize
>operation has ended, which would be the cue to regenerate a properly
>sized bitmap.

Yes, but does all that not depend on the sizing style of the system
- stretch/move outline or stretch move painted image

The one time you /know/ that the b/g canvas is /needed/ is in the
Paint event - one might as well forget about the Resize event

>> Hmm - do you think the Invalidate is necessary ?
>
>Depends on the nature of the striped background. If the number of
>stripes remains constant and they get thicker when the control grows,
>then Invalidate is definitely necessary.

True - but the OP is sticking with the same size
- if the 'scaling' of the background is dependant on the size of the
ClientRect then one might as well check that, and repaint the lot,
rather than ask Windows to tell the control to repaint itself

Hmm - could be a candidate for StretchDraw

>When a control grows, Windows
>only repaints the part that just became visible. When a control shrinks,
>Windows might not repaint the control at all.

... Ah - you mean the Paint event might not fire - gottit
- good point - not a problem here, but worth remembering

>So if the backgorund image
>is proportional to the size of the control, then you need to repaint the
>whole thing. I think TPanel has a related property, called something
>like FullRepaintOnResize.

I'll check that out - yup - it is: FullRepaint ( on WM_SIZE )

>> I'm also inclined to suggest that he makes his background Canvas
>> slightly larger than the Screen
>> - a little jiggling with coordinates would guarantee stripes being in
>> the right place regardless of the ClipRect
>
>Another approach, the usefulness of which depends on the thickness of
>the stripes, would be to use a patterned brush. You can set up an 8x8
>bitmap that matches the stripe pattern, the top four rows in one color
>and the bottom four in another. Assign the brush handle in the panel's
>CreateParams method, and Windows should handle the background painting
>automatically.

That is a really cute idea - just abolish the problem - neat.

Loading