double buffered CDialog
Peter Melchart
mean each control, but the whole thing.
i'm thinking on something like overriding the device contect with a
memoryDC which would be used by all controls and then at the end be
blitted to the original DC. i've not seen any examples on that specific
topic so far. is this possible at all?
regards
Peter
Tom Serface
SetRedraw(false) to stop updates then turn it back on again to have the
final version displayed with SetRedraw(true). I've done this in the past to
get rid of some flickering when I'm updating a lot of different controls,
although it doesn't happen very often.
Tom
"Peter Melchart" <do...@spam.com> wrote in message
news:IFJXd.112336$2e4....@news.chello.at...
Joseph M. Newcomer
drawing directly on the dialog is a design error, and should be avoided completely.
Usually what is intended is more correctly handled by simply placing a static control on
the dialog and using a subclassed CStatic to do the drawing.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Johan Rosengren
Not knowing the real problem, nevertheless one way to speed up dialog
redraws when moving and hiding/showing lots of them is using
BeginDeferWindowPos/DeferWindowPos/EndBeginDeferWindowPos.
Johan Rosengren
Abstrakt Mekanik AB
"Peter Melchart" <do...@spam.com> a écrit dans le message de
news:IFJXd.112336$2e4....@news.chello.at...
Peter Melchart
> Key question here: why?
> There are occasionally reasons to draw on a dialog, but mostly
> drawing directly on the dialog is a design error, and should be avoided completely.
> Usually what is intended is more correctly handled by simply placing a static control on
> the dialog and using a subclassed CStatic to do the drawing.
> joe
i don't want to draw directly on the dialog, i want to have control over
all the standard controls in the window ( buttons, rich edit controls,
... ). so when the window is updated i don't want each control to draw
itselt directly on the window dc but on a memdc and when all controls
are finished i want copy that memdc to the dialog dc. actually... that
would be direct drawing to the dialog.
but would it be possible to create a static control of any kind, and at
some point let all other controls of the dialog becom child windows of
the static control. that way i could handle the onDraw event of the
static control and draw all controls in a memdc and then copy the memdc
to the frontdc. would that work ?
regards
Peter
Joseph M. Newcomer
doesn't need to be drawn, nothing will happen. Each window has a life of its own. When you
say "the window is updated", that applies independently to each window (control) on the
dialog. It is completely meaningless to talk about using some memdc to represent all the
controls, since that is nonsensical; when copied to the dialog, it will update the dialog
background and nothing else; the controls will remain untouched. I think you have
completely and utterly misunderstood how window drawing is done, so you are trying to
solve a nonexistent problem in an inappropriate and nonworkable fashion. Direct drawing to
the dialog means drawing to the surface of the dialog. The windows are not part of the
dialog; they are separate windows which are child windows of the dialog. Bottom line: you
are confused. Forget it. It isn't going to work, and it can't work. In fact, any attempt
to make it work is going to have to be so utterly bizarre that even if you could figure
out how to do it, you would end up with a completely unmaintainable mess. Controls are
not drawn on the dialog; each control is its very own window and draws itself. It is worth
pointing out that your attempt to "optimize" performance will almost certainly reduce
performance significantly.
Why do you think a complicated non-solution to a trivial problem is going to buy anything?
joe
Joseph M. Newcomer [MVP]
David Ching
LockWindowUpdate() / UnlockWindowUpdate(), as a possible alternative to the
already suggested SetRedraw().
-- David
http://www.dcsoft.com
David Ching
news:umr131hh8l0b38v73...@4ax.com...
> Why do you think a complicated non-solution to a trivial problem is going
> to buy anything?
Avoiding flicker and optimizing display performance (with double buffering
or some other technique) is not a trivial problem.
-- David
http://www.dcsoft.com
Joseph M. Newcomer
only. You cannot possibly solve the flicker problem in the way you are suggesting.
Avoiding flicker IS trivial. One key technique is to avoid any use of UpdateData, which
causes a lot of flickering as static and edit controls get re-updated. Since I don't use
UpdateData, I never have a flicker problem except in individual controls. And the ways of
avoiding this are well-known, and often do NOT involve needing an offscreen bitmap (for
example, simply invalidating the minimal region required for update usually is
sufficient). "Optimizing display performance" is usually best addressed by a variety of
other means; the offscreen bitmap often pessimizes performance because the entire bitmap
has to be drawn first, and only then a piece of it is transferred to the actual screen.
So again, the issue is well-understood, and has to be localized to each control.
void CMyEdit::SetWindowText(LPCTSTR s)
{
CString old;
CEdit::GetWindowText(old);
if(old != s)
CEdit::SetWindowText(s);
}
is a truly trivial solution to a flickering edit control; substitute CStatic in a CStatic
subclass and you have optimized flicker in a CStatic text control. Hard to imagine a more
trivial solution.
The hardest anti-flicker issue I had to deal with was in updating a real-time scrolling
graph. That did involve using ScrollWindow to slide the graph to the left, and not doing
any drawing on the left side of the scrolled area, neither one of which was particularly
challenging. Other anti-flicker I've done involves only doing a very careful computation
of the minimal region to be invalidated, which is not terribly hard in most cases.
So it is more important to investigate the trivial solutions first.
joe
Joseph M. Newcomer [MVP]
David Ching
> If a control flickers, you optimize the performance of that control, and
> that control
> only. You cannot possibly solve the flicker problem in the way you are
> suggesting.
>
Agreed, but the OP explicitly said the whole dialog and not a control. I
don't really understand the problem he's trying to solve, but you're right,
dialogs don't inherently flicker, so it must be some control he has on it
that could be individually optimized, or else he is getting a DC for the
dialog and drawing on it directly, which I agree should be discouraged.
-- David
http://www.dcsoft.com
Joseph M. Newcomer
flicker (probably caused by misuse of UpdateData) and decides that the "whole dialog"
needs to be optimized, instead of looking at the root causes and cures. Eliminating all
use of UpdateData is the first and most important step along the way. I find that usually
after that is done, the flicker problem has disappeared and there is therefore no need to
engage in anything more complex. And most people who talk about "optimizing display
performance" usually have so many misconceptions about what they are talking about that
the key thing is to find out if they even know what the problem is (optimizing display
performance can be critical when there is an actual performance problem, but I have found
that most people who think they need to optimize display performance have no data to even
suggest that display performance is even an issue. Only after such data is obtained is
there justification for worrying about it--and there frequently is, but not nearly as
frequently as people seem to think).
joe
Joseph M. Newcomer [MVP]
River Ross
controls flicker when you resize something etc. its gotta be flickering
like crazy before it would be a usability issue.
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:_9kYd.8085$C47....@newssvr14.news.prodigy.com...
Peter Melchart
the whole update process. thing is, i want to paint a background image
on a dialog with some controls that are adjusted to the dialog size. so
when updateing the size of that dialog, i painted the background (in
OnPaint) and then all buttons/edit fields were drawn over the background
which caused a terrible flickering when resizing the dialog.
this just made me wish it would be possible ( like in 3d apps ) to make
the whole window belive that there's no window dc but a memory dc
instead where all controls would update themselves into and later when
all drawing is done i would have copied that memorydc to screen. ok. i
understand that's not possible.
another approach - and i guess a much cleaner one - would be to handle
all the background drawing in OnEraseBackground but before that subtract
all control/child window rects from the drawing/clipping rect somehow. i
guess ExcludeClipRect would be the way to go. so the background would
only be drawn on those areas of the dialog where no other control would
then be drawn afterwards. this would avoid flicker pretty good i guess.
if that fails as well i will just end up creating my own controls where
i have total control of, i guess ;)
thnks anyway
Peter
David Ching
"Peter Melchart" <pe...@dont.smam.me.com> wrote in message
news:u5VCXqzJ...@TK2MSFTNGP14.phx.gbl...
I think painting the background in OnEraseBackground will do it for you.
Just draw your bitmap at that time. The dialog has the WS_CLIPCHILDREN
style, so all the Windows controls on top of your background will be
automatically clipped out when you paint your background.
One more thing: don't call the inherited OnEraseBackground(), as that will
paint a solid gray background before you paint your bitmap, which isn't
necessary. As long as your bitmap covers every pixel in the dialog, that's
all that's needed.
Hope this helps,
David
http://www.dcsoft.com
Joseph M. Newcomer
different approaches. One simple method is to handle the WM_ENTERSIZEMOVE and simply set a
flag that causes OnPaint to do nothing, and reset it in WM_EXITSIZEMOVE. Note that your
suggested approach will not in any way change this problem, because it is not related to
the problem of resizing. Another approach is to modify the WM_ERASEBKGND. My own
preference is to put a CWnd on the dialog, behind all the other controls, and handle its
OnPaint. You can declare a class without the CS_HREDRAW and CS_VREDRAW attributes, which
reduces the tendency to force a complete redraw on a resize. This gives you more degrees
of freedom on when and how you redraw.
There is no need to "subtract" the controls out if you do the WS_CLIPSIBLINGS style on the
CWnd you create; it will be properly clipped, so you don't need to compute clipping
regions. WS_CLIPCHILDREN would work for the dialog, I think, but since I don't believe in
drawing on the dialog I've never tried to solve this problem (I have used the CWnd trick
to get fancy backgrounds on a dialog).
There is certainly no need to create your own controls, particularly because they will not
change this problem in the slightest.
joe
Joseph M. Newcomer [MVP]
Joseph M. Newcomer
addition, some people are "flicker-sensitive" and can suffer migraines or even epileptic
seizures from even short exposures to rapid flickers. Except for the resize flicker,
almost all flicker problems can be easily solved; the resize takes only a little bit of
work.
joe
Joseph M. Newcomer [MVP]
Mark Randall
- Mark R
David Ching
"Mark Randall" <mar...@REMOVETHISgoogle.ANDTHIScom> wrote in message
news:OOfCZZMK...@TK2MSFTNGP10.phx.gbl...
> Because it makes our releases look like we can't code for sh*t.
>
> - Mark R
>
Yes, our bosses may or may not be able to appreciate the subtle details of
our implementations, but they sure can tell flicker when they see it and
assume the rest of our code is equally laden unoptimized.
-- David
http://www.dcsoft.com
songzude
[url]http://www.microsoft.com/msj/0597/c0597.aspx[/url]
--
songzude
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------