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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Thu May 9 16:19:11 CEST 2013


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

Then it's fairly strange it had any effect. I am quite sure it did
have some effect.

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

Fullscreen used to use different code.

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

I think my solution is better :-).
Though that has more to do with the associated code cleanup.
Might be worth just trying to remove that wait for map.
Do you know if there is a chance of other strange effects of not
waiting?
For example some OpenGL drivers crashing when creating a context
before the map request was processed?
Though even if, this waiting for map notify might be just as useless
for that?


More information about the MPlayer-dev-eng mailing list