Qt+OpenGL on Linux within VirtualBox

[agarny]

Hi,

I am using Qt 5.6.2 LTS to develop my application, which requires OpenGL support. To build and test my application on Linux, I use Ubuntu 14.04 LTS within VirtualBox 5.1.18.

Until a couple of hours ago, I was experiencing the problem described here by @mConnolly82 and, thanks to him, I was able to go a bit further.

Only a bit, though, since my OpenGL scene is now completely and my application's menu doesn't work anymore (FWIW, my application works fine on both Windows and macOS). Not only that, but I am now also getting the following warning:

OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU

I googled around and there is very little information about it and, as far as I can tell, no resolution for it. Still, it looks like it might be a VirtualBox-related warning?

Whatever the case, I was wondering whether anyone had ever come across my issue and, if so, how s/he had solved it?

Cheers, Alan.

[agarny]

FWIW, I am getting the same behaviour with Qt Creator. I mean the Welcome panel (which is QML-based and therefore OpenGL-based, right?) is completely black and Qt Creator's menu just doesn't work. However, I am getting different warning/error messages:

QOpenGLFramebufferObject: Unsupported framebuffer format.
Cannot update Qt version information: /opt/Qt/5.3/gcc_64/bin/qmake cannot be run.
QOpenGLFramebufferObject: Unsupported framebuffer format.

[jsulm]

@agarny Why do you use such an old Qt version?

[agarny]

@jsulm ?! This is the LTS version of Qt, so I would rather use that version than the latest version, which may not be as stable for what I need to do. Simple as that.

[agarny]

@jsulm Interestingly enough, some colleagues of mine are still using Qt 4.8 and, when it comes to OpenGL at least, I have found that (very) old version to be behaving much better than Qt 5.6.2 LTS.

This being all said, I might give Qt 5.8 a quick try tomorrow to see whether it makes any difference, but I am not too optimistic.

[Rondog]

I have noticed that OpenGL support on VirtualBox is not very good. I have tried some programs that use OpenGL on on VirtualBox (Windows guest) and found they do some strange things. I consider it unreliable.

The errors you list make sense. QOpenGLWidget renders to a frame buffer then copies this to the window. The older QGLWidget rendered directly to to the hardware and the new method solves a few problems (like QRubberBand for example). If there is a problem creating the frame buffer then a black screen is the likely outcome.

I would suggest testing this on a real computer running your target OS's. If you know it works on these systems then this narrows down the source of the problem (a bit).

[agarny]

I have noticed that OpenGL support on VirtualBox is not very good. I have tried some programs that use OpenGL on on VirtualBox (Windows guest) and found they do some strange things. I consider it unreliable.

Yes, it's clearly unreliable, although my application actually works fine in my Windows virtual machine. It's just with my Linux virtual machine that I am having problems.

The errors you list make sense. QOpenGLWidget renders to a frame buffer then copies this to the window. The older QGLWidget rendered directly to to the hardware and the new method solves a few problems (like QRubberBand for example). If there is a problem creating the frame buffer then a black screen is the likely outcome.
I would suggest testing this on a real computer running your target OS's. If you know it works on these systems then this narrows down the source of the problem (a bit).

Yes, I have asked a colleague of mine to try it on his native Linux machine and it's kind of working. Kind of because we have different dockable windows, including a OpenGL-based dockable window and, now, when we undock a non-OpenGL-based dockable window and try to redock it, then it may or not show as docked.

So, the bottom line is that there is clearly an issue with Linux+OpenGL in VirtualBox, but there is also one with native Linux+OpenGL. Not good at all. Time for me to try with a newer version of Qt to see if it makes any difference, even though I am not very optimistic about it...

[agarny]

@jsulm: here is a concrete example of why I use 'such' an old version of Qt. To try to solve my problem, I thought I would try to build my project using Qt 5.8 and well... after having addressed a couple of issues related to some methods having become obsolete, my application now crashes upon start up. Great! Some googling around tells me that this is a Qt bug that will apparently be fixed in Qt 5.8.1 (see here). Then again, Qt 5.9 is due to be released at the end of next month, so who knows it might take precedence over Qt 5.8.1

So, yes, I prefer to stick to an LTS version of Qt than keep upgrading to the latest version of Qt, not to mention that at the rate at which newer versions of Qt are being released, I would probably be spending my time trying to get my project to work with the latest version of Qt. Clearly, I have other things to do, such as solving the problem I described above...

[jsulm]

@agarny I never said you have to upgrade to each new Qt version. I just was wondering why you're using Qt 5.5 while Qt 5.8 is current version. Usually new versions contain bug fixes (and sometimes new bugs). Sometimes it is worth to try with a newer version if you have issues.

[Rondog]

I noticed a problem with dock windows recently that I wasn't able to solve. You mentioned OpenGL and dockable window so maybe it is less of an OpenGL problem then you think.

In my case I found the dock widget would not draw the widget contents 50% of the time when undocked. This only happened on Windows (OSX and GNU/Linux worked fine). My solution was to prevent the window from completely undocking in Windows (yeah, more of a kludge than a fix).

I am using Qt 5.6.0 which is close to what you have.

[agarny]

@Rondog My application is plugin-based, so I can deactivate the OpenGL side of my application and, if I do so, I don't get the docking/undocking issue anymore (FWIW, this issue only affects Linux).

Anyway, that OpenGL-based dockable window was just for my tests. In the end, we are not planning on having a dockable window for our OpenGL-related work. In fact, I have quickly hacked something that will ressemble what we want to do with OpenGL and, when it comes to our other dockable windows, everything works as expected. So, I am OK with that.

Just out of curiosity, why use Qt 5.6.0 and not Qt 5.6.2?...

[Rondog]

Just out of curiosity, why use Qt 5.6.0 and not Qt 5.6.2?...

Just lazy I guess (maybe). In the old days I always had the latest released version of Qt.

When I move to a new Qt version it is a lot of work. I compile everything from source and I have several systems that I do this on that run different OS's and versions. It takes a while to get everything working again.

I also need to make sure everything works properly when I move to new versions. If there is a problem it can be a real pain to work around the issues on the fly. Some things are obvious and some only show up under certain conditions. Qt has been pretty good in this area so it is not a big risk (but it is not risk free either).

I am aware that 5.8 is out (and 5.9 is right around the corner). I have been thinking about moving in this direction but I also need to run stuff on WinXP as well. The version I have now runs from WinXP to Win10 (possibly from Win2000 to whatever follows Win10). This is really ideal in my case and I don't want to give it up just yet.

[agarny]

@Rondog I understand and appreciate what you are after, but I was just talking about upgrading from 5.6.0 to 5.6.2, which ought to be fine (although we never know, I agree).