http://bugs.winehq.org/show_bug.cgi?id=15549
Summary: Colobot Demo installer does not fully redraw installation window during install progress phase Product: Wine Version: 1.1.5 Platform: PC URL: http://www.ceebot.com/download/demo/colobotdemo17e.exe OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: nodisgod@yahoo.com
Created an attachment (id=16531) --> (http://bugs.winehq.org/attachment.cgi?id=16531) Colobot Demo installer window screenshot
With today's Git (wine-1.1.5-507-ge20ef50), in the process of testing bug 13932, I noticed that when the installer is at the file copy progress phase, some elements of the window are not redrawn properly. A screenshot is attached.
http://bugs.winehq.org/show_bug.cgi?id=15549
scguy318 nodisgod@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, Installer
http://bugs.winehq.org/show_bug.cgi?id=15549
Robert Wm Ruedisueli esd45@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |esd45@earthlink.net
--- Comment #1 from Robert Wm Ruedisueli esd45@earthlink.net 2008-10-08 03:45:50 --- I've noticed this bug in many programs. Windows mandates to backpaging on, while Linux and several other OS default to it off.
Thus, some programs assume that pages that never change will never be lost, and thus will not redraw them when a redraw command is filed.
This is a simple architectural difference that could be patched in several ways.
I think this should be filed under a wider bug if other people confirm my results on more programs.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2008-10-08 03:55:32 --- (In reply to comment #1)
I've noticed this bug in many programs. Windows mandates to backpaging on, while Linux and several other OS default to it off. Thus, some programs assume that pages that never change will never be lost, and thus will not redraw them when a redraw command is filed. This is a simple architectural difference that could be patched in several ways. I think this should be filed under a wider bug if other people confirm my results on more programs.
It's not clear what you mean by "backpaging", drawing "pages", and "architectural difference". Painting in Wine is implemented internally, and is triggered by repainting requests of applications and X expose events.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #3 from Robert Wm Ruedisueli esd45@earthlink.net 2008-10-08 04:28:09 --- (In reply to comment #2)
It's not clear what you mean by "backpaging", drawing "pages", and "architectural difference". Painting in Wine is implemented internally, and is triggered by repainting requests of applications and X expose events.
yeah, back-paging is an old X11 extension term, I probably shouldn't be using it. I should use a more descriptive. In fact I shouldn't even look at this from a X11 server-side perspective, even if that's where I think the problem is.
The best way to describe this is that there is a difference in behavior between X11 and Windows. Windows MANDATES that video drivers store the content of windows that are behind other windows remain in video memory, through a complex method.
X11 implements this through an extension called "back paging" which it copies a replica or "back page" of each window in an off screen buffer page, in the video memory or memory allocated for quick transfer to the video card, in order to restore if the program takes too long to do so itself, when called. I mentioned these memory pages above as pages.
Now an easy solution is best to render all wine windows using off screen extensions than copy them to the screen. This consumes a little more memory, but actually saves processor time in redraws and properly replicates Win32 default behavior.
Sorry about taking the hardware-driver perspective without notice on a bug report that was in software phrasing.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2008-10-08 04:41:37 --- (In reply to comment #3)
Now an easy solution is best to render all wine windows using off screen extensions than copy them to the screen. This consumes a little more memory, but actually saves processor time in redraws and properly replicates Win32 default behavior.
Wine never renders the windows, nor copies them from an off screen memory. All Wine does is just generates the WM_PAINT messages which are either handled by applications on their own or passed to default handlers.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #5 from Robert Wm Ruedisueli esd45@earthlink.net 2008-10-09 00:14:05 --- (In reply to comment #4)
(In reply to comment #3)
Now an easy solution is best to render all wine windows using off screen extensions than copy them to the screen. This consumes a little more memory, but actually saves processor time in redraws and properly replicates Win32 default behavior.
Wine never renders the windows, nor copies them from an off screen memory. All Wine does is just generates the WM_PAINT messages which are either handled by applications on their own or passed to default handlers.
Well yeah, come to think of it, where was my head the other day. I could not explain one thing in easy terms.
Of course, Wine doesn't do it that way, it currently relays through the standard X11 methods, this is the problem. X11 behaves differently than windows. We just need to find a way to get around this when programs don't consider that undocumented Windows behavior may change.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-10-09 00:56:41 --- (In reply to comment #5)
Of course, Wine doesn't do it that way, it currently relays through the standard X11 methods, this is the problem. X11 behaves differently than windows. We just need to find a way to get around this when programs don't consider that undocumented Windows behavior may change.
I'd suggest to stop speculating, the problem needs to be investigated first.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #7 from Robert Wm Ruedisueli esd45@earthlink.net 2008-10-09 04:46:39 --- (In reply to comment #6)
I'd suggest to stop speculating, the problem needs to be investigated first.
Yes, we are saying the same thing and yet not understanding each other, it is futile and I should search for the appropriate bug I was describing, and come back with more solid info. I do know what trace run to do, I just hope I can find the bug I'm looking for.
http://bugs.winehq.org/show_bug.cgi?id=15549
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #8 from Austin English austinenglish@gmail.com 2010-06-04 01:12:49 --- Still present in wine-1.2-rc2-111-g9aa9a12.
http://bugs.winehq.org/show_bug.cgi?id=15549
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #9 from Frédéric Delanoy frederic.delanoy@gmail.com 2011-05-31 15:09:43 CDT --- Confirmed in 1.3.21
http://bugs.winehq.org/show_bug.cgi?id=15549
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #10 from GyB gyebro69@gmail.com 2012-04-08 01:54:15 CDT --- Still present in wine-1.5.1-197-g73e7346.
http://bugs.winehq.org/show_bug.cgi?id=15549
--- Comment #11 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-05-29 04:04:40 CDT --- Still in wine-1.5.31-42-g97f501
https://bugs.winehq.org/show_bug.cgi?id=15549
Jarkko K jarkko_korpi@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarkko_korpi@hotmail.com
--- Comment #12 from Jarkko K jarkko_korpi@hotmail.com --- The issue is still at 1.7.18
But I never see the background image you attached.
Not sure what it should look like when it's doing it right.
Also when you run the installer, it has weird characters I think that's another bug.
After you press "Setup".
Also the game seem to have odd weird colorspace...
https://bugs.winehq.org/show_bug.cgi?id=15549
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de Component|-unknown |user32
--- Comment #13 from Béla Gyebrószki gyebro69@gmail.com --- Still in wine-1.7.34-74-gcf92569
The patch from wine-staging fixes the issue for me: https://github.com/wine-compholio/wine-staging/blob/master/patches/user32-Di...
Fedora 21 XFCE 4.10
https://bugs.winehq.org/show_bug.cgi?id=15549
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |focht@gmx.net Resolution|--- |DUPLICATE
--- Comment #14 from Anastasius Focht focht@gmx.net --- Hello Béla,
thanks for testing.
I'm resolving this as dupe of 35652 since I don't want my analysis there go to waste (even if this report is older).
Thanks
Regards
*** This bug has been marked as a duplicate of bug 35652 ***
https://bugs.winehq.org/show_bug.cgi?id=15549
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=15549
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.ceebot.com/downl |https://web.archive.org/web |oad/demo/colobotdemo17e.exe |/20190914175454/http://www. | |ceebot.com/download/demo/co | |lobotdemo17e.exe