VirtualBox

Ticket #6187 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Accel OpenGL window out of date until glxSwapBuffers is called -> Fixed in SVN

Reported by: TravisCobbs Owned by:
Priority: major Component: 3D support
Version: VirtualBox 3.1.4 Keywords: OpenGL
Cc: Guest type: Linux
Host type: Windows

Description

When accelerated OpenGL is enabled, it only works right for applications that call glxSwapBuffers frequently. Applications that don't do this when they aren't updating prevent any other windows from being displayed over the OpenGL window, and leave the OpenGL window behind when the application window is moved.

To reproduce this, install the qt4-demos package in Ubuntu. (I did this in Ubuntu 9.04, but it should do the same thing in Ubuntu 9.10.) Once qt4-demos is installed, run /usr/lib/qt4/examples/opengl/hellogl/hellogl. Once that has launched, just move its window. Notice that the OpenGL window gets left behind. Then, move some other window over the top of the OpenGL area. Notice that the OpenGL area obscures the other window even though the other window is supposed to be over the OpenGL window.

Drag one of the sliders in the hellogl UI and it will update its display, which triggers a call to glxSwapBuffers, and as soon as it does this, everything is fine again. You can't really tell that other windows on top work because dragging the sliders also brings the hellogl window to the front. However, if swap buffers were called in the background, the clipping problem would go away. To see an example of this, just run /usr/lib/qt4/examples/opengl/2dpainting/2dpainting. Notice that 2dpainting doesn't exhibit any of the problems listed. That appears to be because it is constantly updating and calling glxSwapBuffers.

Change History

comment:1 Changed 4 years ago by joekrahn

I reported this a long time ago in #5848, with additional comments earlier under #3261. Still no follow-up messages. The other issue, not mentioned here, is that the accelerated OpenGL window is positioned incorrectly when the host window uses scrolling to display the guest display (i.e. when auto-resize is off).

In #3261, I included some example code for a user-space work-around that repeatedly sends XExpose events to a target window. It might be possible to make a more automated OpenGL-updater daemon, but I don't see any way to query which X11 windows have an OpenGL context associated.

comment:2 Changed 4 years ago by leonid

It a known issue. To be exact there're some other calls which are triggering position/clipping updates as well.

comment:3 Changed 4 years ago by leonid

  • Summary changed from Accel OpenGL window out of date until glxSwapBuffers is called to Accel OpenGL window out of date until glxSwapBuffers is called -> Fixed in SVN

comment:4 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use