Opened 10 years ago

Closed 22 months ago

Last modified 22 months ago

#9457 closed enhancement (wontfix)

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 (last modified by vadz)

On the web page:

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
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 (21)

comment:1 Changed 10 years ago by wojdyr

  • Component set to wxMSW
  • Keywords flickering added

comment:2 Changed 9 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 and 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 9 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 9 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 9 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 9 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 9 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 9 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.

comment:9 Changed 2 years ago by oneeyeman

If you are reading this and can verify that there is no flickering with either wx3.0 or even better - latest Git HEAD, it would be great.

Otherwise if the flickering is still present, can you clearly describe how this can be seen? Either with some modifications to any of wxWidgets samples or what needs to be done to see it.

Thank you.

comment:10 Changed 22 months ago by oneeyeman

There is still no code to test this with.
But I'm wondering whether we should keep this ticket open - Windows XP lifecycle is ended and so did support for it in wxWidgets.

Any opinion?

comment:11 Changed 22 months ago by ThePonderer

It seems short-sighted for WX not to support XP, as many people are still running it. That being said, I was under the impression that WX had started using this attribute by default for new windows. You don't really need code to test it - all you have to do is look at the window creation code and see if the attribute is on by default. Yet another way is to resize a window in XP and see if there's obvious flickering - especially in a status line help. On the other hand, M$'s spy++ will give the attributes of a created window (at least, I THINK that utility did that). Perhaps you could test with XP compatibility mode. You could see if a minimal window created with WX has this attribute. I think its good to close, just as long as there has been e.g. no code regression.

comment:12 Changed 22 months ago by catalin

FWIW Windows XP is still supported in 3.1.0, and the earlier comment claiming the contrary is inaccurate.

comment:13 Changed 22 months ago by vadz

  • Description modified (diff)
  • Resolution set to wontfix
  • Status changed from new to closed

Yes, XP is still supported, but we won't add any new code to address XP-specific problems such as flickering which happens under XP only.

Anyhow, I still have no idea what is this ticket really about, so I think we can indeed close it.

comment:14 Changed 22 months ago by ThePonderer

It's not complicated what this ticket is about. For stuff to look right under XP, one needs to be able to use the WS_EX_COMPOSITED attribute on new windows. When I opened it, specifying it on window creation was unsuccessful. What's hard about that?

comment:15 Changed 22 months ago by vadz

It wasn't obvious to me that using WS_EX_COMPOSITED for all windows is the right thing to do. In any case, we're not going to do it now and risk introducing regressions under a platform we almost never test under any more (and it's not even a risk but almost a certainty because I vaguely remember many problems with this style under XP).

comment:16 follow-up: Changed 22 months ago by ThePonderer

I think it is currently what is done, but I'm not sure. I am under the opinion that that it IS the right thing to do in all cases. I have moved on to another framework than WX since then, or I'd test it myself. I suggest testing it to see that it is done in all cases - and if not, making it so.

Suppose it's not being done. If somebody created a window and specified that attribute in creating a window, if you get the attribute working right, it only starts working the way it was intended. If somebody creates a window in WX and doesn't specify it, then having it enabled breaks nothing. In my understanding, it's a display only property. In my opinion, it probably works correctly already - but that should be verified. I've given you three ways of verifying it, and explained the display anomalies it creates when resizing a window. In my opinion, a simple test or inspection of the source is most likely all that's required to close this ticket. In my opinion, more than ZERO work is required to close this ticket.

comment:17 Changed 22 months ago by ThePonderer

This ticket is about display on XP. If you don't see strobing on a message on the status line when resizing a window on XP, WS_EX_COMPOSITED will virtually certainly be on.

comment:18 in reply to: ↑ 16 Changed 22 months ago by ericj

Replying to ThePonderer:

I am under the opinion that that it IS the right thing to do in all cases.

Most certainly not. I experimented with it myself many years ago and with complicated layouts controls would just disappear when resizing the frame and this flag was set.

Anyone who really (thinks he) needs this flag can easily set it himself.

comment:19 Changed 22 months ago by ThePonderer

That would be fine with me.

comment:20 Changed 22 months ago by ThePonderer

This ticket was about that not working, when one sets it himself/herself.

comment:21 Changed 22 months ago by ThePonderer

Come to think about it, I'm not sure whether or not you'd see the strobing effect on an LCD monitor. That was years ago. Still, if you create a window with the WS_EX_COMPOSITED attribute, Spy++ should be able to tell you if it actually works. Testing on XP would be better, but if nobody is available to test in XP, you may be stuck with testing in XP compatibility mode.

(Controls that don't display with this attribute on may be related to custom painted controls. The idea, is that with this attribute on, the whole thing doesn't have to be redrawn each time. I had a program with a VERY complicated GUI, but no user-painted controls; and all this attribute did was eliminate the strobing effect.)

Note: See TracTickets for help on using tickets.