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

[Jens Stimpfle]

On Thu, May 09, 2013 at 03:35:03PM +0200, Reimar Döffinger wrote:
> 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.

What has effect or not is not an X client's beer. Anything managed
client's request might not have an effect, and many WM's don't care
about ConfigureRequests, but at most for size hints.

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

You dont have to wait for a MapNotify. You can also do XMapWindow()
directly followed by XMoveResize(). From the WM's point of view, it
should make no difference if you wait for MapNotify in between because
it doesn't know when you receive it. If the purpose of the blocking code
is to block until *the WM* gets a MapNotify (to only then request
resizing), well, then it failed to do so (it can't be done).

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

Again, any X client must be prepared to get any size any time. That's
exactly what happens when the user resizes the mplayer window using his
standard window manager.

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

Sane clients even have to handle wrong aspect ratio (think fullscreen
for the simplest case).

> I think the simplest fix with least impact is to just process the
> events instead of discarding them.

My point. And my guess was that the cleanest way to implement this is to
remove the blocking code.