[vlc-devel] xcb/window.c fullscreen in mozilla plugin
remi at remlab.net
Fri Jun 25 06:07:53 CEST 2010
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:
> 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
> 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.
More information about the vlc-devel