Guest OpenGL Regions Draw Over Everything Else in VM

[William Swartzendruber]

When running OpenGL applications inside VirtualBox the acclereated portion of the VM window overlaps whatever else happens to be in the same spot. This does not affect other windows on the host.

I am running:

Linux 2.6.28.2 (x86-64) X Server 1.6. RC2 (DRI2/UXA) GNOME 2.24.3 Compiz-Fusion 0.7.8 VirtualBox 2.1.2

I have posted a screenshot at ​http://www.wswartzendruber.net/images/virtualbox_opengl_overlap.png

[Leonid Lobachev]

Does it happen when player is not in the paused state?

[William Swartzendruber]

Yes.

[William Swartzendruber]

Host Log

[William Swartzendruber]

I have attached my VBox.log. During this session, I played a portion of a video using OpenGL acceleration and clicked the Start menu in the guest so that it got covered by the playing video.

[Leonid Lobachev]

Hmm, looks rather strange. Could you run smplayer on guest from a console with exported CR_DEBUG_FILE=c:\glog.txt and attach that file please?

winkey+r, cmd, enter

set CR_DEBUG_FILE=c:\gllog.txt smplayer

or whatever it's binary called.

[Leonid Lobachev]

Some symbols got eaten, set and smplayer are 2 different command you have to type in the console window on guest. And I forgot to mention, play something in smplayer and move/resize some other windows a bit, then close smplayer and copy/attach logfile after it please.

[Technologov]

bug #2818 seems similar to this one.

-Technologov

[Zach Pearce]

I'm experiencing something similar to this.

Linux Host/Windows Guest

I have a java app which normally paints in 2d, but can also spawn an open gl window. When this window opens, you can still navigate in 3d space fine, however when you try to close the window, it AND its parent 2d window still draw on the screen and there is no way to get rid of them without restarting the vm. If you click the start button, it comes up behind the remnants of the windows, so it's not freezing the vm.

[Jos Krahn]

I am using a windowed OpenGL program with a Vista host and a Linux guest. It appears that the clipping space gets updates whenever the application redraws the screen. t gets updated with an expose event, but not when part of the render area gets obscured. Unfortunately, a minimized window does not get redrawn, so the rendering area remains, masking out all other windows. The render area also does not update if the VM window is smaller than the VM display, and the scrollbars are moved.

Maybe a quick work-around would be to periodically send expose events for OpenGL windows.

[Jos Krahn]

Below is a quick-and-dirty utility to send XExpose events. Compile with gcc as:

gcc -o xexcpose xexpose.c -lX11

Then run as follows, where the hex value is the target window ID:

xexpose 0x4d000003

You can find the window ID with xwininfo. With this running, OpenGL window clipping gets updated, including when the window is minimized. An equivalent hack is likely to help Windows guests.

The scrolled VM window is drawn in the wrong place, regardless of window refreshing. It assumes the upper left is always (0,0), and ignores the scroll position.

/* xexpose.c */
#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
  Status stat=1;
  XEvent ev = {Expose};
  Display *dpy=XOpenDisplay(NULL);
  Window w=(Window)strtoll(argv[1],NULL,0);
  printf("window=%p\n",(void*)w);
  ev.xexpose.display = dpy;
  ev.xexpose.window = w;
  while (stat) {
    stat = XSendEvent(dpy,w,True,ExposureMask,&ev);
    XFlush(dpy);
    sleep(1);
  }
  return 0;
}

[Technologov]

This is fixed in v3.1.0 (tried on both Windows and Linux hosts, with Windows XP guest)

-Technologov

[GortiZ]

I've almost the same issue on v4.1.18 but the other way around: windows with linux guest #10755 Could it be due to the same problem or something similar? Should I mark that one as a duplicate of this one and reopen this bug?