[vlc-devel] xcb/window.c fullscreen in mozilla plugin

[Rémi Denis-Courmont]

On Friday 25 June 2010 03:04:22 David Menestrina, you wrote:
> I found your email info in the git logs, and I figured you might be the
> best person to help me out.
> 
> I am trying to fix VLC bug 3777:
>    https://trac.videolan.org/vlc/ticket/3777
> 
> Everything I know about XCB and fullscreen I learned in the past two days,
> but the problem seems to be that setting _NET_WM_STATE_FULLSCREEN has no
> effect on an embedded window.

Window managers do not track non-top windows. Adjusting an embedded window to 
screen size would not make much sense anyway; it would be cropped to its 
parent window borders in any case.

> Therefore, I have written some code to set
> the window's parent to the root window before setting the window to
> fullscreen.

> My first question is if you think this is a good approach,  or if it would
> be better to create a new window for fullscreen mode.

Unfortunately not. That's why I did not implement it in the first place. 
Reparenting someone else's window seems like a terrible concept. I have not 
tried and it might just work with Intrinsics as used in the Mozilla plugin. 
But I expect some ugly side effects in general, depending on which UI toolkit 
the application is using and how so.

> My second question is about some problems I'm having with the current
> approach.  In order to do the reparenting correctly, I must put the window
> back where it was when exiting fullscreen mode.

That's precisely why the idea is bad. There is no way to do this correctly in 
all cases. The UI toolkit might change the layout of the embedding window's 
parent window. Or it might simply reparent the embedding window, thus 
defeating the fullscreen mode.

> Putting the window back
> involves saving the location and parent of the embedded window, which
> require calls to xcb_get_geometry and xcb_query_tree, respectively.
> 
> What I'm seeing is that about 30% of the time, my code works fine.  About
> 70% of the time, my code hangs waiting for the reply to xcb_get_geometry.
> As I said, I have no real experience with XCB, so if you have any ideas as
> to why xcb_get_geometry_reply would hang forever, that would be helpful.

Most probably the XCB events thread dequeued the reply from within Thread() 
before you called xcb_get_geometry_reply(). Then you get stuck forever waiting 
for a message that is already gone. Note that none of the current Control() 
code paths ever wait for a reply.


I like to think that if an application told LibVLC to embed the video, then 
that application should be responsible for fullscreen handling. That's how the 
VLC Qt4 and Skins2 user interfaces work.

Alternatively, we could change the XCB drawable plugin to create an 
intermediary window as a parent to video and child to the embedding window. 
Then reparenting becomes a non-issue. But this would require some amount of 
event handling to keep the layout in sync. Also, the application would loose 
input events in fullscreen mode - which is precisely why fullscreen mode 
handling was changed in the first place.

-- 
Rémi Denis-Courmont