X window id from an OpenGL/glx thread to Qt
-
Hi,
I'm doing heavy texture streaming (multiple live video streams) with OpenGL using pixel puffer objects (using QtOpenGL/QGLWidget is not an option here) in Linux.
The texture streaming is done by a separate, custom OpenGL cpp module and thread (separate from Qt libraries completely)
However, I want to stream into x windowses that are operated by the Qt subsystem (i.e. the videos appear in the widgets)
I have two options:
[Option 1]: Create a qt widget, get the x window id of the widget and pass that to my custom OpenGL module
Qt => window_id => custom OpenGL module
In the custom OpenGL module I then use that window_id with glxMakeCurrent as a rendering target.
[Option 2]: Create an x window in my custom OpenGL module. Pass the id of the x window to the Qt module, i.e.:
custom OpenGL module => window_id => Qt
This is "healthier", because I can create a custom x window having the correct parameters corresponding to glx framebuffer configurations, i.e.: glx framebuffer config => visual => colormap => parameters for creating the X window
A "foreign" window can then be used in Qt like this (in PyQt):
q_window =QtGui.QWindow.fromWinId(win_id)
q_widget =QtWidgets.QWidget.createWindowContainer(q_window,parent=parent)Both options work in principle, but ..
In (1), after several hours, the x-window system starts to choke up .. windowses are unresponsive, etc. Very weird. I am suspecting some sort of overflow of signals in the x-window system (and therefore, in the qt event loop) .. ?
Option (2) does not suffer from this problem, but of course, I'll loose all window interaction..! i.e., there is no way to get mouse click events, drag'n'drop etc. from the custom "q_widget" (see above)
So, the questions are:
a) In option (1), there seems to be something unhealthy.. I'm not sure what it is as it goes quite deep into the X window system. Any insight on this?
b) How can I get mouse click, etc. events from a "foreign" window into the Qt subsystem?
-
Hi,
What version of Qt are you using ?
What Linux distribution ?
Do you encounter the same troubles if your Qt GUI is built directly with C++ ?
What is your graphic stack ? -
Qt5
Ubuntu 16.04 (4.4.0-36-generic)
uh.. dunno
X.org Intel drivers, glx 1.4, OpenGL4.2 (Core Profile), Mesa 17.2.4I'd just like to know if I doing something perverted here .. (using Qt instantiated x window from another thread with glx - I mean, is that sound).
And one thing .. I forgot to call "XInitThreads" .. have to benchmark that as well.
-
Qt 5 is a bit vague ;)
Convoluted maybe but I don't think it's perverted although I'd be curious to know why QtOpenGL is not an option.
-
Qt 5 is a bit vague ;)
Convoluted maybe but I don't think it's perverted although I'd be curious to know why QtOpenGL is not an option.
Decoding a large amount of full-hd videos realtime with a single thread (to avoid opengl context swapping) .. could get complicated with with QThread(s). See here what I'm trying to do:
https://elsampsa.github.io/valkka-core/html/process_chart.html
Advertisement coming: Its production-ready pretty soon and a lot of interest to Qt-users. :)
