[MPlayer-dev-eng] Bugreport/Patch: x11 video backend has wrong geometry assumptions

[Jens Stimpfle]

On Wed, May 08, 2013 at 10:24:50PM +0200, Reimar Döffinger wrote:
> On Wed, May 08, 2013 at 03:04:53PM +0200, Jens Stimpfle wrote:
> > On Wed, May 08, 2013 at 06:47:44AM +0200, Reimar Döffinger wrote:
> > > Without waiting for map, our size/position request will be ignored in
> > > many cases, causing at least -geometry to break.
> > 
> > But then that's probably not mplayer's fault and fighting bugs in other
> > applications with workarounds in one's own application is never the
> > appropriate solution (In this case it actually breaks with the simplest
> > window manager I could think of--the one I'm currently working on).
> 
> I considered it reasonable behaviour.
> A hidden/non-mapped Window doesn't necessarily have a position,
> so it's not exactly wrong that setting a position has no effect.

My understanding is that size/position are orthogonal attributes.

> > IMO the only sane way is to *not* ignore the events until the first
> > MapNotify. No window manager can be expected to re-send those events.
> 
> Well, that kind of leads us to starting from the start:
> What is the actual issue? Because the theory is really that none
> of the events from that early on really should matter.

That's wrong, they do matter, and they must be handled if our goal is to
know the actual window size (one could also query it but as you pointed
out that's probably not a good solution). X clients can't expect to
receive further configure events.

When this bug is triggered, mplayer thinks its window size was different
than it actually is, and won't output the movie in a format to fit the
window.

Here's a detailed explanation.

1) WM registers itself with X as window manager.

2) mplayer is started to play a movie with x11 output and calls
XMapWindow()

3) as there is a WM, the WM is sent MapRequest event.

4) the WM decides to put the mplayer window to a preferred position/size
by calling XMoveResizeWindow() or similar and subsequently calls
XMapWindow().

Note that a tiling window manager has exact and static ideas about what
the window size/position should be. In general it doesn't moveresize the
window after the initial moveresize. Note also that it's totally ok for
the WM to moveresize the window before mapping it: That's why it's
called a window manager. Also generally it's at least not unusual to be
resized before being mapped. Xterm even waits for 5 seconds to be
resized before wanting to be mapped (which is another bug in my eyes).

5) mplayer receives events in that order: First ConfigureNotify (which
contains the changed window size/position), but this one it currently
ignores, then MapNotify.

6) And here is the problem: mplayer starts to play the movie: it
mistakenly assumes the old wrong window size (fullscreen I guess), but
the window size really is the one set by the WM. If the actual size is,
for example, 0.5screenwidth/0.5screenheight, only the upper left
quadrant of the movie is actually shown.

7) Now mplayer can call XMoveResizeWindow() as often as it likes: Even
if the WM answers all resulting ConfigureRequests which it receives with
another XMoveResizeWindow() call to the current window size/position,
this won't result in any ConfigureNotify events sent to mplayer: Because
the size/position didn't change, the X server won't send them.  And this
is exactly the point why it is wrong to ignore any events from the
start.

> > I was inable to reproduce the -geometry breakage you mentioned, with any
> > of icewm, fluxbox and fvwm.
> 
> Couldn't reproduce it here. So maybe it's not really an issue any more.
> On the other hand as I said before I didn't consider it unreasonable.
> So I'd like to at least fully understand the issue.
> I guess the issue is that MPlayer really doesn't like the window manager
> changing the size behind its back.

Any client must be prepared to be resized any time. It's not a
request/reply model.

I've attached a self-contained example wm where the bug is triggered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testwm.c
Type: text/x-csrc
Size: 1597 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130509/831bf475/attachment.bin>