From: Steve P. <st...@ba...> - 2003-12-14 03:38:24
|
Hi, Yep I've done it. But my implementation SUCKS and breaks a few things so I won't commit yet. First, the HOW: Before you read on, be prepared for nastiness. When WM_ERASEBKGND is received in CommonMsgLoop it is discarded (so we stop backround erasing happening). When WM_PAINT is received in CommonMsgLoop a compatible DC and bitmap for the window is created, and the DC handle is then sent back to the window in a WM_PRINT message for drawing (WM_PRINT can be sent to make the window do it's drawing in another DC). Now the DC that's just been WM_PRINTed on is blitted back onto the window's DC. Here are the problems: 1. WM_PRINTCLIENT didn't do what I wanted (I expected it would draw everything in the client area on a bitmap the size of the client area, but this didn't want to work) so I had to use WM_PRINT, and do some sums to calculate how to crop the resultant bitmap, which included blank areas for the non-client-area. 2. It's kind of slow. This is probably because it has to create a DC and bitmap every time a WM_PAINT occurs, and it has to draw the whole window (which it was doing anyway). It also does FillRect to clear the background of the new bitmap to the right colour, and I couldnt find a faster way of doing it than this. 3. It fills the background of the new DC with the colour for COLOR_BTNFACE, whatever your OS. This probably looks right on XP too, I haven't tested it. I tried to use the color set in the window's class using GetClassLong(hwnd,GCL_HBRBACKGROUND), but this always just returned "5" rather than a brush handle, which is odd. Incidentally, 5 is the value of COLOR_WINDOW, which Win32::GUI chooses as the class color on a win2k machine (like mine) - could this point to a more elegant way of fixing the WinXP white-background bug, I.e. the class color should be a brush rather than a color?. 4. Graphics objects no longer show up (DCs don't seem to support WM_PRINT). 5. Setting WS_CLIPCHILDREN results in massive flickering (the opposite of what it used to do) and causes no background to show. Despite these 5 points, on my machine it's not NOTICEABLY slow and my GUIs feel so much more solid with it. Perhaps this feature should be optional? No commit until I have some of your advice, questions or suggestions. Steve |
From: Glenn L. <pe...@ne...> - 2003-12-14 05:21:36
|
On approximately 12/13/2003 7:41 PM, came the following characters from the keyboard of Steve Pick: > Hi, > > Yep I've done it. But my implementation SUCKS and breaks a few things so I > won't commit yet. > 4. Graphics objects no longer show up (DCs don't seem to support > WM_PRINT). > > 5. Setting WS_CLIPCHILDREN results in massive flickering (the opposite of > what it used to do) and causes no background to show. Well, I don't really understand a lot of what you said, and I don't have any applications that flicker with the current GUI, so I guess I'd have to say that if *anything* gets "broken" by this "enhancement", that it should definitely be an "extra cost option", rather than the default. -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |
From: Steve P. <st...@ba...> - 2003-12-14 16:19:02
|
Hi, > > 4. Graphics objects no longer show up (DCs don't seem to support > > WM_PRINT). > > > > 5. Setting WS_CLIPCHILDREN results in massive flickering (the opposite of > > what it used to do) and causes no background to show. > > Well, I don't really understand a lot of what you said, and I don't have > any applications that flicker with the current GUI, so I guess I'd have > to say that if *anything* gets "broken" by this "enhancement", that it > should definitely be an "extra cost option", rather than the default. All my application widgets flickered when I resized the windows, especially tree and listviews. This fix prevents the erase->redraw mentality of Windows, which is a stupid way of doing things in the 1st place. It would be easy to add an option "-noflicker" to all windows so that you can explicitly say "I want to use the non-flicker drawing routines". I will do this. Steve |
From: Reini U. <ru...@x-...> - 2003-12-14 17:28:22
|
Steve Pick schrieb: > All my application widgets flickered when I resized the windows, especially > tree and listviews. This fix prevents the erase->redraw mentality of > Windows, which is a stupid way of doing things in the 1st place. It would be > easy to add an option "-noflicker" to all windows so that you can explicitly > say "I want to use the non-flicker drawing routines". I will do this. Thanks, good idea. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Laurent R. <ro...@cl...> - 2003-12-14 18:36:38
|
Hi, Garside Trevor say on win32::GUI Users list flicker problem when resize window can be remove by set default class style to 0. In GUI.xs, RegisterClassEx : wcx.style = 0; // CS_HREDRAW | CS_VREDRAW; // TODO (default class style...) It's look better when resize main window. I don't have samples whith lot of flicker problem. So, don't know if it's sufficient. Laurent. > > > 4. Graphics objects no longer show up (DCs don't seem to support > > > WM_PRINT). > > > > > > 5. Setting WS_CLIPCHILDREN results in massive flickering (the > opposite of > > > what it used to do) and causes no background to show. > > > > Well, I don't really understand a lot of what you said, and I don't have > > any applications that flicker with the current GUI, so I guess I'd have > > to say that if *anything* gets "broken" by this "enhancement", that it > > should definitely be an "extra cost option", rather than the default. > > All my application widgets flickered when I resized the windows, especially > tree and listviews. This fix prevents the erase->redraw mentality of > Windows, which is a stupid way of doing things in the 1st place. It would be > easy to add an option "-noflicker" to all windows so that you can explicitly > say "I want to use the non-flicker drawing routines". I will do this. > |
From: Steve P. <st...@ba...> - 2003-12-14 22:24:01
|
Hi, I tried this, it doesnt solve my particular problem at all, in fact it doesn't make the slightest difference. My window has a *lot* of widgets (it's a whole application made in The GUI Loft with several panes), so the flicker is probably very noticeable for me. Also, if you have a flatscreen monitor (LCD) the flicker is much less noticeable. Steve ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: "Steve Pick" <st...@ba...> Cc: "Win32 GUI Hackers" <per...@li...> Sent: Sunday, December 14, 2003 6:36 PM Subject: Re: [perl-win32-gui-hackers] Success with flicker-free windows! > Hi, > > Garside Trevor say on win32::GUI Users list flicker problem when resize > window can be remove by set default class style to 0. > > In GUI.xs, RegisterClassEx : > wcx.style = 0; // CS_HREDRAW | CS_VREDRAW; // TODO (default class > style...) > > It's look better when resize main window. > I don't have samples whith lot of flicker problem. > So, don't know if it's sufficient. > > Laurent. > > > > > 4. Graphics objects no longer show up (DCs don't seem to support > > > > WM_PRINT). > > > > > > > > 5. Setting WS_CLIPCHILDREN results in massive flickering (the > > opposite of > > > > what it used to do) and causes no background to show. > > > > > > Well, I don't really understand a lot of what you said, and I don't have > > > any applications that flicker with the current GUI, so I guess I'd have > > > to say that if *anything* gets "broken" by this "enhancement", that it > > > should definitely be an "extra cost option", rather than the default. > > > > All my application widgets flickered when I resized the windows, > especially > > tree and listviews. This fix prevents the erase->redraw mentality of > > Windows, which is a stupid way of doing things in the 1st place. It would > be > > easy to add an option "-noflicker" to all windows so that you can > explicitly > > say "I want to use the non-flicker drawing routines". I will do this. > > > > |
From: Glenn L. <pe...@ne...> - 2003-12-15 21:22:12
|
On approximately 12/14/2003 8:22 AM, came the following characters from the keyboard of Steve Pick: > All my application widgets flickered when I resized the windows, especially > tree and listviews. This fix prevents the erase->redraw mentality of > Windows, which is a stupid way of doing things in the 1st place. It would be > easy to add an option "-noflicker" to all windows so that you can explicitly > say "I want to use the non-flicker drawing routines". I will do this. Ah. Tree and listviews are not commonly found in my current applications. No wonder I haven't noticed the flicker. -noflicker sounds like a good way to go, though, as your solution does sound somewhat drastic, in the sense that there are incompatibilities and side-effects, which, although perhaps not terribly severe, could affect some applications. -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |