Opened 7 years ago

Last modified 6 years ago

#9457 new enhancement

Flicker-free drawing/WS_EX_COMPOSITED XP attribute

Reported by: codelurker Owned by:
Priority: normal Milestone:
Component: wxMSW Version:
Keywords: flickering Cc: codelurker
Blocked By: Blocking:
Patch: no

Description

On the web page:

http://wiki.wxwidgets.org/Flicker-Free_Drawing

you can see some of the attempts to resolve the
flicker issue. You can see the diffs there from
the wxChandler project, and how they solved the
problem (although their software has unrelated
performance issues). Basically, they added a
wxWS_EX_BUFFERED_DRAW attribute for all windows, that
turns on the XP attribute WS_EX_COMPOSITED. It is
really only needed for top level windows, and
NO_FULL_REPAINT_ON_RESIZE and wxCLIP_CHILDREN are not
needed to end the flickering on resizing things.
Extra credit would be to look over the differences
with the canonical wxWidgets code there and
see if they did anything else that is important to
flickering. Practically speaking, I've been using
wxWidgets with that attribute for some time, and it
seems to solve the lion's share of the flickering
problems. By and large, the coding is already done.
Shouldn't be too hard.

Change History (8)

comment:1 Changed 6 years ago by wojdyr

  • Component set to wxMSW
  • Keywords flickering added

comment:2 Changed 6 years ago by ThePonderer

I notice that the MSW SetDoubleBuffered() function has made it into 2.8.9, although it is not documented yet. The changesets here andhttp://trac.wxwidgets.org/changeset/53930 respond to this issue request. This is a related issue. The problem is, as described here, is that these changes do not appear to work yet, although they look like they should.

comment:3 Changed 6 years ago by vadz

  • Status changed from new to infoneeded_new

I don't understand what exactly doesn't work, could you please be more precise? The wiki page you link to is full of different things (including many obsolete or misleading if not directly wrong ones) so it'd be really better to have a small patch to e.g. minimal sample showing the problem.

Also, if you have some code which does work, what does it do exactly?

comment:4 Changed 6 years ago by ThePonderer

  • Status changed from infoneeded_new to new

The only real point, is that windows created under XP don't have the WS_EX_COMPOSITED attribute set. Except for a commented out refresh to toolbars, the only thing that is of use on that whole page is setting the WS_EX_COMPOSITED. I think the toolbar issue has already been addressed on another ticket, so setting the WS_EX_COMPOSITED is the only thing on the whole page of real interest. Everything else is just various attempts to accomplish what that attribute does. If you simply build the statbar sample and resize it, you will notice a slight flickering or strobing effect of the text on the statusbar. This is enough to identify the problem. This may not seem like a big deal, but the effect is quite pronounced on tree controls and listboxes sometimes. It's a dead giveaway that an app is from the Windows 98 era to a end user, most often. I expect the same will happen with the notebook in the Listbook style. If you make the wxChandler changes and recompile the libraries, and then add a statement "SetExtraStyle(wxWS_EX_BUFFERED_DRAW);" to your initialization, the text on the status bar loses its slight flickering effect. As stated on the new section on the webpage, in 2.8.9, you can do a "SetDoubleBuffered(true);", and it looks like it ought to work, but I noticed significant flickering while resizing an app I am developing which contains a wxListbook, and in which I used the SetDoubleBuffered statement instead; thus signifying that it in fact was NOT working. Changing back to my wxChandler-style statement, the flickering was gone again. It looks like it should work, and it compiled just fine, but it did not work. There are probably utilities out there that would allow you to click on a window and see if attributes such as the WS_EX_COMPOSITED attribute is set, but the statusbar sample should work fine to show the problem. All samples will not have this attribute set by default, as things now stand in wxWidgets. In the statbar sample, just put either the wxChandler-style statement, or the SetDoubleBuffered statement as the last statement in the MyFrame constructor in order to test. The "XP Look and Feel" add-in in Code::Blocks has nothing to do with this. It instead creates a manifest file which prevents yer app from running painfully slow on a system it wasn't compiled on. (That being said, I've finally broke down and chosen Visual C++ Express as my editor.) Precision is my middle name; although I've had some difficulty getting my mom to start using it.

comment:5 Changed 6 years ago by vadz

What are these "wxChandler changes"? I.e. is there a patch somewhere I could apply to test them?

Concerning WS_EX_COMPOSITED, I'm pretty sure that it does gets set on the window when you call SetDoubleBuffered() and you can use Spy++ utility included in MSVC or Platform SDK to check it. If the flickering still persists it must be due to something else, i.e. "wxChandler changes" must include something more than just setting this style but I don't know what would this be.

comment:6 Changed 6 years ago by ThePonderer

The wxChandler changes are those which are at the bottom of the wiki page on flickering under the heading of "what finally worked". If you read the start of that section, they are all there. You can ignore most of the diffs at the bottom of that section as well, as the text explains. I'm a bit of a n00b, and don't know how to make a formal patch, nor have I learned SVN yet. I am using vc++ Express, and don't have Spy++. The wxChandler changes are an if statement to set the attribute is to define it, and in your own projects source, to set it. Other than that, the only change other than commented out code, is to to comment out a refresh on the scrollbar. I think it highly unlikely they are interfering with SetDoubleBuffered. Check Spy++ yourself, how about, if you really want to be sure? You shouldn't need to. If you can't see an improvement in the text on the statusbar on the statbar app, it isn't working. If you are, it is. It's that simple. If it works for you, my getting it working is probably not the issue. If needed, I can make two .exe's that show the difference, but then if you check the before and after of the statbar sample, (or probably moreso the notebook sample in the Listbook style, much more noticeably), either you will or won't see a difference. While the statbar flickering without is faint, I have never failed to notice a difference with and without the WS_EX_COMPOSITED XP attribute set. In getting these changes from the wxChandler guy, I was pretty much out of my depth, and yet in my understanding, it is pretty simple to see if it is working or not. If so, this issue goes away. Why not test it yerself?

comment:7 Changed 6 years ago by ThePonderer

PS: There is a #define for wxWS_EX_BUFFERED_DRAW in a PS which fallows the "What Finally Worked" section you will need, also.

comment:8 Changed 6 years ago by ThePonderer

Let me try that again.

PS: There is a #define for wxWS_EX_BUFFERED_DRAW in a PS which follows the "What Finally Worked" section you will need, also, if you want the wxChandler changes, which you should not need, but which do work. My middle name may be precision, but sometimes it takes me a few revisions.

Note: See TracTickets for help on using tickets.