! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Screen obscured when game changes resolution (using Wine)
Status:
RESOLVED: FIXED

Comments

Description Frédéric Delanoy 2012-04-03 01:36:31 CEST
When running many types of games (generally old ones like Baldur's Gate, Age of Empires, Galactic Civilizations, ...) with Wine, part of the screen is obscured when resolution is changed.

Works OK when e.g. using 'metacity' instead of 'xfwm' WM in XFCE, so likely not a bug in Wine.

To reproduce (using wine): install the demo (from the URL), run it => the initial screens are not correctly displayed (I only see the low part).

Seems like xfwm is trying to resize to the original resolution when it shouldn't.
For instance, see http://bugs.winehq.org/show_bug.cgi?id=29907#c9

See also http://bugs.winehq.org/show_bug.cgi?id=30213

Config: Ubuntu 11.10 x86_64; XFCE 4.8.0.2; xfwm 4.8.2

Could be linked to xfce bug 5592, but the original poster used an old wine version and xfce version, so I wasn't sure.
Comment 1 Olivier Fourdan editbugs 2012-04-03 09:13:03 CEST
(In reply to comment #0)

> Seems like xfwm is trying to resize to the original resolution when it
> shouldn't.
> For instance, see http://bugs.winehq.org/show_bug.cgi?id=29907#c9

xfwm4 does not change the resolution by itself, it has no code to do so.
Comment 2 Fab 2012-04-03 10:14:36 CEST
Created attachment 4290 
lower part of the screen is reversed

Tested the behavior under gentoo with wine 1.4 and xfwm-4.8.3 with retail versions of :
 - Baldur's Gate (BG1)
 - Baldur's Gate 2 (BG2)
 - Age of Empires 2 (Conquerors)

Black areas happens with BG1 and Conquerors but not with BG2.
Downgrading wine to 1.3.30 seems to fix the problem for BG1 and Conquerors, except that the lower part of the Conquerors screen is reversed (see attached screenshot).
Comment 3 Olivier Fourdan editbugs 2012-04-03 10:15:44 CEST
The download on fileplanet does not work and the demo for Galactic Civilizations crashes Wine, so I have no way to reproduce this issue.

Note that "it works in metacity so it's a bug in xfwm4" is not necessarily valid, the same happens in icewm as well reading from the various Wine bug reports you linked. Each window manager may implement things differently, causing bugs to appear in some app, that does not necessarily mean it's a bug in the window manager.

Anyway, as I said, I cannot reproduce so there's very little chance that I spend much time on this.
Comment 4 Frédéric Delanoy 2012-04-03 17:05:35 CEST
(In reply to comment #3)
> The download on fileplanet does not work and the demo for Galactic
> Civilizations crashes Wine, so I have no way to reproduce this issue.

Odd I just downloaded it without problem: http://download.cnet.com/Galactic-Civilizations/3000-2119_4-10204231.html?tag=lst-0-1 should work

I never heard of GalCiv crashing wine, though.
Which wine version are you using? Standard wine package in distribs tend to be outdated: maybe you could try with wine 1.4 or 1.5.x?
One reason could be buggy OpenGL drivers (ATI/intel ones have bugs exposed by wine, nouveau some; nvidia blobs are generally fine).

> Note that "it works in metacity so it's a bug in xfwm4" is not necessarily
> valid, the same happens in icewm as well reading from the various Wine bug
> reports you linked. Each window manager may implement things differently,
> causing bugs to appear in some app, that does not necessarily mean it's a
> bug in the window manager.

One of the wine devs in this area thinks otherwise: "...this doesn't change the fact that the window manager resizes the fullscreen (after the mode change) window to the (original) desktop size instead of keeping it at the current screen size"

cf. http://bugs.winehq.org/show_bug.cgi?id=30213#c18

> Anyway, as I said, I cannot reproduce so there's very little chance that I
> spend much time on this.
Comment 5 Olivier Fourdan editbugs 2012-04-03 17:10:15 CEST
(In reply to comment #4)
> One of the wine devs in this area thinks otherwise: "...this doesn't change
> the fact that the window manager resizes the fullscreen (after the mode
> change) window to the (original) desktop size instead of keeping it at the
> current screen size"
> 
> cf. http://bugs.winehq.org/show_bug.cgi?id=30213#c18

Again, there is no code in the window manager to change the resolution, if you can point me to any portion of code in xfwm4 that changes the resolution, I would be very interested to hear about it...

xfwm4 does *not* change the resolution, maybe something else does, but this is not the window manager, the window manager listen to XRANDR events and adjusts the windows positions/size to match the new screen size but it won't and cannot change the resolution on its own.
Comment 6 Olivier Fourdan editbugs 2012-04-03 17:16:17 CEST
(In reply to comment #5)
Ah wait, maybe I misread that sentence:

"the window manager resizes the fullscreen (after the mode window to the (original) desktop size instead of keeping it at the current screen size"

Ok so he means resize the fullscreen window _from_ Wine, not change the resolution...

 - Does the app (Wine) changes the resolution multiple times in row? Lim,e quickly changing resolutiosn several times at once?

 - Have you tried with current (xfce 4.9) code?
Comment 7 Olivier Fourdan editbugs 2012-04-03 17:41:16 CEST
(In reply to comment #4)
> I never heard of GalCiv crashing wine, though.
> Which wine version are you using? Standard wine package in distribs tend to
> be outdated: maybe you could try with wine 1.4 or 1.5.x?
> One reason could be buggy OpenGL drivers (ATI/intel ones have bugs exposed
> by wine, nouveau some; nvidia blobs are generally fine).

Wine version is fine, it's wine-1.5.1 on Fedora 17.

But it looks like it's nouveau indeed:

exe: nvfx_state_fb.c:162: nvfx_framebuffer_validate: Assertion `0' failed.
wine: Assertion failed at address 0xf7722430 (thread 0027), starting debugger...
Can't attach process 0026: error 5
Comment 8 Frédéric Delanoy 2012-04-03 18:16:12 CEST
(In reply to comment #6)
> (In reply to comment #5)
> Ah wait, maybe I misread that sentence:
> 
> "the window manager resizes the fullscreen (after the mode window to the
> (original) desktop size instead of keeping it at the current screen size"
> 
> Ok so he means resize the fullscreen window _from_ Wine, not change the
> resolution...
> 
>  - Does the app (Wine) changes the resolution multiple times in row? Lim,e
> quickly changing resolutiosn several times at once?

AFAICT,
1. initial resolution change at startup for displaying "demo screen", then intro video
2. resolution change to display the game menu (correctly displayed).
3. resolution change when 'Quit'-ting the game (similar issues with "exit screens")

>  - Have you tried with current (xfce 4.9) code?

I'll try that.
Comment 9 Olivier Fourdan editbugs 2012-04-05 09:19:26 CEST
(In reply to comment #8)
> >  - Have you tried with current (xfce 4.9) code?
> 
> I'll try that.

Yeap that'd be must appreciated. 

The games under Wine won't work with nouveau (see above) and NVidia driver fails to install on my F17 laptop, so I don't have any way to try to reproduce.

Reason I'm asking to test against 4.9 is because legacy fullscreen code was removed in 4.9. 

Previously, an application mapping a window without decoration the size of the screen would have been automatically treated as "fullscreen", to please older apps that don't know about EWMH, but nowadays that should not be required so this code is gone in 4.9.

I suspect this issue *might* be related to that code for legacy apps, so maybe it won't occur in 4.9.
Comment 10 Frédéric Delanoy 2012-04-06 01:34:23 CEST
(In reply to comment #9)
> (In reply to comment #8)
> > >  - Have you tried with current (xfce 4.9) code?
> > 
> > I'll try that.
> 
> Yeap that'd be must appreciated. 
> 
> The games under Wine won't work with nouveau (see above) and NVidia driver
> fails to install on my F17 laptop, so I don't have any way to try to
> reproduce.
> 
> Reason I'm asking to test against 4.9 is because legacy fullscreen code was
> removed in 4.9. 
> 
> Previously, an application mapping a window without decoration the size of
> the screen would have been automatically treated as "fullscreen", to please
> older apps that don't know about EWMH, but nowadays that should not be
> required so this code is gone in 4.9.
> 
> I suspect this issue *might* be related to that code for legacy apps, so
> maybe it won't occur in 4.9.

I was trying to compile 4.9/4.10pre to test, but a fix/workaround got committed in wine:
http://bugs.winehq.org/show_bug.cgi?id=30213#c18

Thanks in any case for the time you spent reviewing this bug report and your helpful comments.
Comment 11 Olivier Fourdan editbugs 2012-04-06 09:15:03 CEST
(In reply to comment #10)
> I was trying to compile 4.9/4.10pre to test, but a fix/workaround got
> committed in wine:
> http://bugs.winehq.org/show_bug.cgi?id=30213#c18

Aaaawww, too bad, I would have liked to know if 4.9/4.10 fixes that
Comment 12 Fab 2012-04-08 14:28:58 CEST
(In reply to comment #11)
> (In reply to comment #10)
> > I was trying to compile 4.9/4.10pre to test, but a fix/workaround got
> > committed in wine:
> > http://bugs.winehq.org/show_bug.cgi?id=30213#c18
> 
> Aaaawww, too bad, I would have liked to know if 4.9/4.10 fixes that

I still have wine-1.4 (without the committed workaround). and I just upgraded to Xfce-4.10pre1 with xfwm4-4.9.0.

This changed nothing to the behavior of this bug : comment #2 is still valid.
Comment 13 Olivier Fourdan editbugs 2012-04-09 18:08:52 CEST
(In reply to comment #12)
> This changed nothing to the behavior of this bug : comment #2 is still valid.

But xfce does not changes the way apps display themselves, how could it "reverse" the lower part of the window of any app?

Are you sure this is the same issue you're talking about? Sound like a different problem to me...
Comment 14 Fab 2012-04-09 19:09:46 CEST
(In reply to comment #13)
> (In reply to comment #12)
> > This changed nothing to the behavior of this bug : comment #2 is still valid.
> 
> But xfce does not changes the way apps display themselves, how could it
> "reverse" the lower part of the window of any app?
> 
> Are you sure this is the same issue you're talking about? Sound like a
> different problem to me...

Sorry for not being clear enough. Yes, I'm sure we're talking about the same bug.

The attached screenshot in comment #2 was to illustrate the fact that black areas disappear with older versions of wine (1.3.30) and the same version of xfwm4. The reversed part in the screenshot is a side effect unrelated to this bug.

Now, to answer your main question :
> Aaaawww, too bad, I would have liked to know if 4.9/4.10 fixes that

I can confirm that black areas still appears in Baldur's Gate and Age of Empires with wine-1.4 and xfwm-4.9.0.
Comment 15 Olivier Fourdan editbugs 2012-04-10 21:47:23 CEST
(In reply to comment #5)
> One of the wine devs in this area thinks otherwise: "...this doesn't change
> the fact that the window manager resizes the fullscreen (after the mode
> change) window to the (original) desktop size instead of keeping it at the
> current screen size"
> 
> cf. http://bugs.winehq.org/show_bug.cgi?id=30213#c18

That's not entirely accurate though.

xfwm4, the window manager, does not resize the fullscreen windows to the original desktop size, actually it was not resizing the fullscreen windows at all... not even to the new desktop size (so the widnow kept its old size).

That's now fixed in git master with commit 1f9b6ef5
Comment 16 Olivier Fourdan editbugs 2012-04-10 21:48:35 CEST
(In reply to comment #14)
> I can confirm that black areas still appears in Baldur's Gate and Age of
> Empires with wine-1.4 and xfwm-4.9.0.

You may retry now with current git, fullscreen windows are now resized to the screen size. If the problem remains, it might be something else.
Comment 17 Fab 2012-04-11 09:15:33 CEST
(In reply to comment #16)
> You may retry now with current git, fullscreen windows are now resized to
> the screen size. If the problem remains, it might be something else.

I have just rebuilt xfwm4-4.9.0 with the patch from git commit 1f9b6ef5. The issue is now fixed !

Bug #8622

Reported by:
Frédéric Delanoy
Reported on: 2012-04-03
Last modified on: 2012-04-11

People

Assignee:
Olivier Fourdan
CC List:
1 user

Version

Attachments

Additional information