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

[Reimar Döffinger]

On Thu, May 09, 2013 at 02:48:29PM +0200, Jens Stimpfle wrote:
> 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.

Huh? What does that have to do with it?
The point is, if we set/request our window position before being
mapped, it might not have any effect. I am saying that this didn't
seem unreasonable to me, since several windowing systems consider
a minimized window one that was moved off the screen.
Our positioning request being ignored is the reason for waiting for the
map.

> > > 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.

Right or wrong is not the point.
A good problem description is the point.
And the problem seems to be easily expressed with "MPlayer does not
handle when the window it gets does not have the requested size".
Until recently that was a fairly pointless thing to fix, because
the result wouldn't be any good anyway (at the very least if the
aspect request is also ignored).
I think the simplest fix with least impact is to just process the
events instead of discarding them.