Home » U++ Library support » Look and Chameleon Technology » Question to UPP developers: the issue with windows rendering (Windows XP)
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29333 is a reply to message #29327] |
Fri, 15 October 2010 14:47   |
porto
Messages: 51
Registered: March 2007
|
Member |
|
|
I have examined in great detail other applications - native, QT apps, and I did not notice anything similar.
There is one screenshot from my video. (VirtualBox+clean WinXP)
In this case, even if the problem with window behind - it's UPP app's window too.
If you want to notice it, try:
| Quote: |
I found a better way to see this issue.
Download this app (it slows down the CPU):
http://www.cpukiller.com/cpukil305.zip
install it, set the "Slow Down Factor" (I set it on 95%), start slowing down CPU. Now, this issue will be visible very well.
|
-
Attachment: f0353.jpg
(Size: 87.13KB, Downloaded 427 times)
[Updated on: Fri, 15 October 2010 17:31] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29368 is a reply to message #29365] |
Sat, 16 October 2010 10:01 |
 |
mirek
Messages: 14164
Registered: November 2005
|
Ultimate Member |
|
|
| porto wrote on Sat, 16 October 2010 02:38 |
And the last question. Why I can't notice something like this issue with other apps?
|
My guess: Because you are not trying hard enough...
| Quote: |
This is an animation of cold start UPP application:
P.S. Thanks for your replies. Sorry for my fault-finding and taken away your valuable time.
|
Well, to be absolutely sure, I have tried to reproduce the problem on slowest computer I have around (Asus EEE with 1.6Ghz Atom, WinXP), found nothing.
My guess is that the effect is caused by particular setup of your machine.
Actually, within WinXP, this effect is normal - but with normal PC, it is so fast that black areas go away before they are send to the monitor.
For some reason, on your machine it is slower. Well, it CAN becaused by some particular set of flags we are using in call to CreateWindow or something like that, however we are not doing anything "illegal", just using normal Win32 API calls.
I would even tried to mingle with these flags to see if I can solve the problem for you, the problem is I cannot even reproduce the damned thing.
You might also consider upgrading your video driver...
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29369 is a reply to message #29368] |
Sat, 16 October 2010 10:24 |
|
mirek
Messages: 14164
Registered: November 2005
|
Ultimate Member |
|
|
OK, I did some test using CpuKiller (btw, useful utility, thanks), setting it at 98%.
It is true that U++ based apps show black corners. The same thing is true for following well known software:
Adobe Reader
IrfanView
Total Commander
DVD Shrink
(stopped testing there).
If Adobe does not see this as problem, neither do I.
Just technical sidenote, to me it looks like technical issue behind the problem is that it depends on the way how the main window is composed. If it has a lot of child widgets, Win32 split painting widget by widget to multiple messages and this way some messages in multitasking system reach other windows. U++ is highly optimized there and paints the window in single pass.
You can even notice that if you slow down things, those windows that do not show the black corners generally paint by parts and for quite a longer time...
I guess there is little I can add here - I did not want to dismiss the issue, but this really is non-issue...
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29534 is a reply to message #29369] |
Wed, 27 October 2010 14:56 |
porto
Messages: 51
Registered: March 2007
|
Member |
|
|
It seems a simple solution was found. In a method:
void Ctrl:: Create0 (Ctrl:: CreateBox * cr) (Win32Wnd.cpp)
Before showing the window, we add an extended style:
cr->exstyle = cr->exstyle | WS_EX_COMPOSITED;
After the window is shown, remove it:
::SetWindowLong(top->hwnd, GWL_EXSTYLE, cr->exstyle ^ WS_EX_COMPOSITED);
It would be nice before to check which version of Windows we have - do it if we have Windows XP or higher.
These simple changes fixed the problem, and the performance still the same.
Can I hope that someone of the developers will make these (or more correct than mine) changes to one of the following buids of UPP?
[Updated on: Wed, 27 October 2010 15:43] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29563 is a reply to message #29539] |
Sat, 30 October 2010 13:45 |
porto
Messages: 51
Registered: March 2007
|
Member |
|
|
There was found, I think, a good way to get away of this "issue" (the temporary addition to an extended style of windows a flag WS_EX_KOMPOSITED *) - but I want to find the reason of it.
Do not judge strictly an amateur in programming. 
After a series of experiments with MS Spy++ utility I made some conclusions, this "issue" has two causes:
1. Child windows of traditional Windows applications have a flag of style CS_SAVEBITS. Child windows of UPP apps, this style does not have (or have, but not all).
After the forced set of this flag to all windows, "issue" only occurs if UPP application is busy, for example when I opening a package in TheIDE or doing "Rescan Code".
2. If UPP app does not busy (idle) and it creates the child window, the parent window is not repainting. But if UPP app is busy and it creates the child window, in this case, for some reason is starting repainting of the parent window or region of it, and CS_SAVEBITS is no longer helps.
If in this case the parent window or region of it does not repaint and all the child windows would have a flag CS_SAVEBITS (like in traditional applications), then the "issue" would not appear (IMHO).
This was only my best guess, do not take very seriously. 
* With WS_EX_COMPOSITED set, all descendants of a window get bottom-to-top painting order using double-buffering. Bottom-to-top painting order allows a descendent window to have translucency (alpha) and transparency (color-key) effects, but only if the descendent window also has the WS_EX_TRANSPARENT bit set. Double-buffering allows the window and its descendents to be painted without flicker.
|
|
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29572 is a reply to message #29563] |
Mon, 01 November 2010 10:03 |
|
mirek
Messages: 14164
Registered: November 2005
|
Ultimate Member |
|
|
| porto wrote on Sat, 30 October 2010 07:45 |
There was found, I think, a good way to get away of this "issue" (the temporary addition to an extended style of windows a flag WS_EX_KOMPOSITED *) - but I want to find the reason of it.
Do not judge strictly an amateur in programming.
After a series of experiments with MS Spy++ utility I made some conclusions, this "issue" has two causes:
1. Child windows of traditional Windows applications have a flag of style CS_SAVEBITS. Child windows of UPP apps, this style does not have (or have, but not all).
|
I guess you have got the term "child window" wrong. CS_SAVEBITS is intended for popups.
| Quote: |
After the forced set of this flag to all windows, "issue" only occurs if UPP application is busy, for example when I opening a package in TheIDE or doing "Rescan Code".
|
For one thing, there are no child windows in U++...  (Except DHCtrl descendants, but that is a special case).
My guess is that WS_EX_COMPOSITED only helps accidentally - it changes repainting process of windows and as side-effect, the effect is gone. In the same time, it is not unlikely that this will still depend on actual windows version, graphics driver etc...
|
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29573 is a reply to message #29571] |
Mon, 01 November 2010 10:21 |
porto
Messages: 51
Registered: March 2007
|
Member |
|
|
I made changes in file Wnd32Wnd.cpp, in method:
void Ctrl::Create0(Ctrl::CreateBox *cr) (begin at line 459)
Added lines are marked in bold:
void Ctrl::Create0(Ctrl::CreateBox *cr)
{
GuiLock __;
cr->exstyle = cr->exstyle | WS_EX_COMPOSITED;
... some code ...
::ShowWindow(top->hwnd, visible ? cr->show : SW_HIDE);
::SetWindowLong(top->hwnd, GWL_EXSTYLE, cr->exstyle ^ WS_EX_COMPOSITED);
... some code ...
}
I really want to find out the cause of this effect. So I want to ask you, if UPP apps windows need repainting some area, they are fully updated or update only the necessary area?
I have achieved the same effect in WinAPI application by locking update in underlying window by LockWindowUpdate():
HWND hWnd, hWnd2;
hInst = hInstance;
hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
hWnd2 = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
ShowWindow(hWnd, SW_MAXIMAZED);
LockWindowUpdate(hWnd);
ShowWindow(hWnd2, SW_NORMAL);
Sleep(1000);
Without LockWindowUpdate() in this code the effect is gone.
My another suggestion (possibly incorrect again): in UPP apps for some reason MS Windows are not immediately sends WM_PAIN command to underlying windows.
I also tried to make the following changes: after the new window is shown, I just completely update the parent window. This is also a solution to the problem, but why Windows does not update a necessary area of parent window automatically not clear to me...
[Updated on: Mon, 01 November 2010 13:45] Report message to a moderator |
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29608 is a reply to message #29572] |
Wed, 03 November 2010 17:07 |
porto
Messages: 51
Registered: March 2007
|
Member |
|
|
As I understood from the description in MSDN the flag of extended style "WS_EX_COMPOSITED" activates the double-buffering at the OS level (it's supported minimum in WinXP), so unlikely it will depend on the graphics card drivers. About making changes in UPP if you agree, I think the better off the flag after the full appearance of the window. About changes in UPP, if you agree, I think it's better to set off the flag after full window rendering instead after non client area rendering, it will give a smoother draw them.
You can make changes like that e.g., or more correctly: (added lines are marked in bold):
1. In file Wnd32Wnd.cpp, at begin of the method (line 459):
void Ctrl::Create0(Ctrl::CreateBox *cr)
{
cr->exstyle = cr->exstyle | WS_EX_COMPOSITED;
...some code...
}
2. In file TopWin32.cpp, at end of the method (line 173):
void TopWindow::Open(HWND hwnd)
{
...some code...
::SetWindowLong(hwnd, GWL_EXSTYLE, ::GetWindowLong(hwnd, GWL_EXSTYLE) ^ WS_EX_COMPOSITED);
}
[Updated on: Wed, 03 November 2010 17:08] Report message to a moderator |
|
|
|
| Re: Question to UPP developers: the issue with windows rendering (Windows XP) [message #29624 is a reply to message #29573] |
Thu, 04 November 2010 14:27 |
|
mirek
Messages: 14164
Registered: November 2005
|
Ultimate Member |
|
|
| porto wrote on Mon, 01 November 2010 05:21 |
I also tried to make the following changes: after the new window is shown, I just completely update the parent window. This is also a solution to the problem, but why Windows does not update a necessary area of parent window automatically not clear to me...
|
It does. Please note that everythings gets updated in the end, even when the effect is visible. What so much bothers you is the pause.
But all these things are affected by timing. Win32 simply sends some messages first, some others later, that is all. Accidentally, for U++ or IrfanView, with certain HW and system config, it means that messages required to repaint nonclient area of window are sent later.
|
|
|
|
Goto Forum:
Current Time: Sat Dec 14 15:18:41 CET 2024
Total time taken to generate the page: 0.04115 seconds
|
Members
Pages
Help
Register
Login
Home
