[MPlayer-dev-eng] Question regarding mplayer and X

[Nicolas George]

Le septidi 7 messidor, an CCXIX, Stephen a écrit :
> I am trying to get electricsheep running as an animated desktop under a

I do not know what electricsheep is, apart from the Rick Deckard's dream.

> compositing window manager combined with fluxbox under X11.  Strictly
> speaking I only use fluxbox for window tiling as I used xbindkeys.  I've
> been having some serious trouble getting mplayer to render to the root
> window in a reliable manner.
> 
> First, I was hoping that you could clarify specifically how X11 treats the
> window separately from other windows.  I have everything working perfectly
> when electricsheep .avi's are rendering to a window.  Passing the '-rootwin'
> argument, or more circuitous routes (xwininfo . . .) result in the video
> rendering and the other windows briefly coming up for air between frames,
> basically flickering.  I don't understand this behavior.

As far as I know, X11 compositing works that way: the compositing manager
asks the server to redirect the subwindows of a particular windows, usually
the root window. When a window is redirected, any drawing operation is done
on a memory buffer rather than on the screen. The compositing manager is
then responsible for displaying the memory buffer someway.

If your compositing manager works by using the root window as an OpenGL
context with double buffering, for example, and rendering the redirected
subwindows as textured polygons, the symptoms you describe are to be
expected: your drawing operations are interlaced with the compositing
manager's.

> Second, I'm running the bumblebee project on an optimus system and

I do not know what bumblebee is either. Nor what an optimus system is.

> I've since been playing around with xprop for the first time, and have
> noticed that fluxbox's alt+f4 window killing feature can't be prevented with
> '-remove _NET_WM_ALLOWED_ACTIONS'.  Is this the intended behavior, and if so
> how can I set the atom _NET_WM_ACTION_CLOSE to disallow it from being
> closed?  If I could prevent it from being closed, moved or minimized then
> this problem would only prevent me from using the fluxbox menus and allowing
> the cursors as I currently have them configured from rendering above
> non-fluxbox maintained windows which would be adequate.

I do not know why you thought I could help you with that. I only did the
low-level work for delete events once, more than five years ago, and this
was not published.

As far as I remember, a window accepts the close messages by adding the
WM_DELETE_WINDOW atom to its WM_PROTOCOLS property, and then reacting to
client messages with that atom.

I do not know how fluxbox works, especially whether it will honor a change
to WM_PROTOCOLS after the window is mapped or if it will use XDestroyWindow
when WM_DELETE_WINDOW is not supported.

> On Sat, Jun 25, 2011 at 12:28 AM, Stephen <kbaegis at gmail.com> wrote:

Please note that top-posting is frowned upon on these mailing-lists.

Also, this is more about the use of mplayer than its development.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110626/aba98864/attachment.asc>