[vbox-dev] Running MeeGo UX correctly inside VirtualBox with OpenGL acceleration

[Feng, Haitao]

Hi Leonid,

Here is the code from mutter-2.28
src/compositor/compositor.c:meta_compositor_manage_screen

"
  info->window_group = mutter_window_group_new (screen);
  info->overlay_group = clutter_group_new ();
  info->hidden_group = clutter_group_new ();

  clutter_container_add (CLUTTER_CONTAINER (info->stage),
                         info->window_group,
                         info->overlay_group,
                         info->hidden_group,
                         NULL);

  clutter_actor_hide (info->hidden_group);
"

There are three groups in clutter container, and clutter container draw them
from bottom to top, first the window group, and then the overlay_group. 

The window group is drawn as you have suspected. And the overlay group could be
drawn by mutter plugins. MeeGo Netbook UX uses the overlay to draw MeeGo panel. I
am not sure whether Gonme-Shell uses the overlay group as I have not read the
Gnome-Shell source codes.

There are two ways to draw texture from pixmap:
1) If the X server has GLX_texture_from_pixmap extension (Please see here for
more details: http://www.opengl.org/registry/specs/EXT/texture_from_pixmap.txt).
    mutter will redirect a window offscreen using XCompositeRedirectWindow
    mutter will create an X Pixmap name of the offscreen window using
XCompositeCreatePixmapName
    mutter will create a GLXPixmap for the named X Pixmap using glXCreatePixmap
    mutter will bind the GLXPixmap as an OpenGL texture by doing:
        glGenTextures (1, &texture);
        glBindTexture (GL_TEXTURE_2D, texture);
        glXBindTexImageEXT (display, glxpixmap, GLX_FRONT_LEFT_EXT, NULL);
2) If the X server has no GLX_texture_from_pixmap extension 
    mutter will redirect a window offscreen using XCompositeRedirectWindow 
    mutter will create an X Pixmap name of the offscreen window using
XCompositeCreatePixmapName.  
    mutter will copy the content of the pixmap into GL texture by glTexImage2D
if there is an update on the pixmap.

As currently GLX_texture_from_pixmap is present in VirtualBox, the 1) is the
flow you have described. 

>From my side, I have disabled the GLX_texture_from_pixmap, and when we create
host peer GL window, I make them invisible by XCompositeRedirectWindow. When
glXSwapBuffer happens, I read the content back by using glReadPixels, and then
use XShmPutImage to update the guest window content and then reply on 2) to draw
the texture. This works and the performance is acceptable. This is a reference,
I will try those work when GLX_texture_from_pixmap is on. I have seen some issue
in MeeGo UX when it is on.

Maybe from beginning we should use off-screen buffer to do the GL rendering
instead of using window. The current essential problem is that when guest wants
to draw a texture/window on guest display, the host draws a window on top of
VirtualBox. And then you have to check the guest window status such as mapping,
clipping and others for host peer window.

Here is a picture of our discussion,

                          texture from pixmap
          guest texture         <------        guest pixmap
               |                  b)                  ^
               |   c)                                 |   a)
               V                                      |   
          host texture drawing  <------       host off-screen buffer
                                  d)

The a), b) and c) form your first/fast solution and the "1). Rendering GL
off-screen and reading window contents back into guest." as I suggested.

The d) is the your future enhancement and the "Rendering GL at host-side and
forwarding guest normal X window contents into host" as I suggested. 

In d), for normal guest X window contents updates, maybe we could register
damage callback for them, and when there is an update, we could draw the host
texture correspondingly.

It seems that we are aligned on this. Could we work together to let VirtualBox
run MeeGo Netbook UX, Gnome-Shell (mutter-based GL compositor) correctly with GL
acceleration?

Thanks
-Haitao

On Mon, Aug 30, 2010 at 07:45:13PM +0800, Leonid wrote:
> Hi, Haitao.
> 
> Could you please point me to the mutter source where it deals with this dual 
> layer rendering?
> 
> I'm not quite sure on this, but I'd suspect Mutter to just force all other 
> application windows to do offscreen rendering via XCompositeRedirectWindow, 
> including other OpenGL apps. And then render it own window using 
> GLX_texture_from_pixmap to access other application pixmap data in his own
> OpenGL context. Please correct me if this is wrong description.
> 
> If the above is correct, then there're clearly 2 things to fix in our opengl
> implementation to make it work.
> 
> 1. Window visibility check function, stubIsWindowVisible from 
> src\VBox\Additions\common\crOpenGL\context.c doesn't take into account that
> window might be redirected offscreen via XCompositeRedirectWindow. 
> Adding a check there will solve the issue with overlapping windows.
> 
> 2. Opengl application (like MeeGo UX plugin) pixmap content updates.
> I think that it's best to go with something similar to what you've suggested in
> "1). Rendering GL off-screen and reading window contents back into guest." 
> Because going 2nd way will require us to "implement guest mutter logic at host 
> side" which will require us to keep track of changes in mutter code etc.
> 
> So, for a first/fast solution I'd go with using glReadPixels to update guest 
> window offscreen pixmap content when application issues glXSwapbuffer or 
> glFlush/glFinish if glDrawBuffer is set to GL_FRONT.
> 
> Typical flow would be something like this:
> 1.MeeGo creates a window W.
> 2.Mutter issues XCompositeRedirectWindow for W, gets access to W offscreen
> storage Pwin by using XCompositeNameWindowPixmap and creates opengl pixmap
> Pogl to use with GLX_texture_from_pixmap by issuing 
> glXCreatePixmap(dpy, ..., Pwin, ...)
> 3.MeeGo creates an OpenGL content and makes it current with W.
> Our code, in stubIsWindowVisible detect that the current window is 
> redirected to pixmap Pwin and sets some flag causing us on 
> glXSwapbuffers(+glFlush/glFinish) to issue glReadpixels and update Pwin.
> 4.Mutter goes in render loop and at some point processes MeeGo window(s),
> issuing glXBindTexImageEXT(dpy, Pogl, ...)
> Our code there, will update associated host texture with content of Pwin
> via glTex[Sub]Image calls.
> Etc.
> 
> As a future enhancement I'd try to avoid unnecessary 
> glReadpixels/glTex[Sub]Image calls this way:
> When we detect that our W is redirected to Pwin, we could force host part to 
> use fbo for window W, binding some texture T as GL_COLOR_ATTACHMENT0_EXT.
> (close functionality could be seen in 
> src\VBox\HostServices\SharedOpenGL\crserverlib\server_muralfbo.c)
> Now when mutter issues glXBindTexImageEXT, we might query host to see if
> there's a FBO redirection for a guest pixmap Pwin and if there's one, we 
> can just bind texture T and there's no need to upload anymore data to host.
> 
> The only problem here is that we need to somehow intercept every guest 
> read/write access to a pixmap Pwin and update it content before read accesses 
> or update T after writes to Pwin. I'm not quite sure how could we intercept 
> calls to XGetImage/XCopyArea etc, but I'm not sure if in this particular case 
> Mutter/MeeGo will ever issue those calls as well.
> 
> Best regards, Leonid.
> 
> 
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> http://vbox.innotek.de/mailman/listinfo/vbox-dev