GNOME Bugzilla – Bug 112241
Using PAspect WM SizeHint results in wrong window sizes
Last modified: 2004-12-22 21:47:04 UTC
I'm the author of tvtime, a realtime deinterlacer (http://tvtime.sourceforge.net). In our development version, we are setting the aspect ratio of our window as follows: XSizeHints hints; hints.flags = PAspect; hints.min_aspect.x = aspect_width; hints.min_aspect.y = aspect_height; hints.max_aspect.x = aspect_width; hints.max_aspect.y = aspect_height; XSetWMNormalHints( dpy, win, &hints ); On startup, we call this with the aspect_width and aspect_height set to the size of our window, calculated for the current pixel aspect ratio. I have a user who is using metacity-2.4.0.92-5 (rh8 current). On their system, the pixel aspect ratio is reported by X to be 1088/1119. We start up with a 746x576 window (4:3 for this pixel aspect) and call the size hint appropriately as above. Metacity then resizes our window to 746x967. We see similar behavior when we go fullscreen (we use _NET_WM_STATE_FULLSCREEN if you support it, I did not check). The size hint causes metacity to resize our window, and we end up not filling the screen correctly. Am I doing something wrong, or is this a bug in metacity? Do you have any advice about how I could handle this better in my code?
The aspect ratio stuff was broken at one point, it should be working in more recent versions, e.g. the one in RHL 9. The ChangeLog entry that fixed this I believe was: 2002-10-18 Havoc Pennington <hp@redhat.com> * src/window.c (constrain_size): fix min aspect handling, patch from Martin Garton #94943 With fullscreen, metacity will prefer to honor the aspect ratio and other size hints over making the window exactly fullscreen; so if you force an aspect ratio that doesn't match the screen's ratio, you might have empty areas around the fullscreen window.
Would be helpful to confirm that the app works with newer metacity, if it does.
I'll try and get the user to upgrade and try a newer version. Your note about the usage of this in fullscreen mode worries me though. Should it not be ignored in fullscreen? If I have tvtime in 16:9 mode and the user toggles the _NET_WM_STATE_FULLSCREEN property, I very much want to show black above and below the video on a 4:3 monitor, otherwise the movie experience really loses out. Should I somehow be disabling the sizehint in fullscreen mode, or when I get a property change event?
Yes, I would say you want to disable the aspect hint in fullscreen mode. There are some tricky race conditions there; there's no way to atomically change both the fullscreen and the size hints at once. The window manager has no way of knowing whether it's OK or not to ignore size hints for a particular app. If you can show black bars, it may be right to omit the aspect hint, and just offer some kind of "snap to the right aspect" feature in the menus. It's possible we could find a better solution by further specifying the relationship of fullscreen/maximized to the size hints and which one "wins" in that case; but right now it's essentially unspecified. wm-spec-list@gnome.org is where discussions of spec extensions/clarifications normally occur.
The bug with the hints seems to be gone in 2.4.34 for another user. I honestly don't know how Red Hat stuff works, but is there a way to have that hints fix backported? I'm really just curious about my options. My application can correctly show black bars all the time and does not require the hints, and we have added a snap-window-size-to-match-content feature. I'll be posting to wm-spec-list about the fullscreen handling.
It's unlikely that we'd do a bugfix update of RHL8 at this point (since RHL9 is out, and this is a relatively esoteric problem). I'd encourage you implement the "right thing" code first, and then add any workarounds temporarily (rather than targeting older releases).
Aspect hints are working in 2.6.1, right? Are all parts of this bug fixed?
working, though perhaps not totally optimally, ui-wise.
Reopen if aspect hints aren't working in 2.6.1 (Or file a new bug with the specific new reproduction instructions, if it isn't clearly the same bug as this one)