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

[Reimar Döffinger]

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.

> > It might be possible to call the check_events code to actually handle
> > those messages though.
> 
> AFAICT check_events() is only for external usage (for example from
> vo_x11.c) because it does not handle anything.

Huh? It handles almost everything, just the redrawing (which should
not matter at this point) and a bit of the reconfiguration (which
should not matter either since it should be done afterwards) are
outside of it.
Even if I was wrong that they don't matter, they are a single int
that can be easily stored.

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

> AFAICT everything the "wait for map" hack is meant to do is to block
> until the MapNotify arrives.  Unfortunately, there is no
> XMaskTypedWindowEvent() but only XCheckTypedWindowEvent() in xlib. I
> think it could be emulated with poll() on ConnectionNumber() and
> XCheckTypedWindowEvent(), but whether it's clean to have a potentially
> infinitely growing events queue is another question.

That went way over my head, I'd rather not have such a complex approach.

> I'd really like to see that problem solved. Do you have more detailed
> information on why technically the "// wait for map" thingie was added?

The details are probably lost in time.

> 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.
This would be solvable by simply querying the actual window size before
returning from that function. (Not necessarily a really good approach
though I admit).