Would usng x windows with opengl cause performance loss?

since opengl is accelerated by hardware if i were to use x windows as buttons on the screen would i run into significant loss of performance?
thanks.

It can be, though it doesn’t have to be. For instance, you can run OpenGL apps on Mesa3D OpenGL drivers without a GPU in your system, and it will do its best with the CPU you’ve got.

…if i were to use x windows as buttons on the screen would i run into significant loss of performance?

Loss of performance over what?

Just drawing buttons with OpenGL isn’t going to be inherently slow, no. As always, it depends on how you draw as to how efficient it is. Efficient code leads yields good performance, though that’s basically a definition.

That said, GUIs tend to be low overhead compared to realtime rendering, so I’m not sure what your performance concerns are. For instance, you rarely need to redraw a GUI, and redrawing it every frame is overkill.

it sounded to me as if he was asking about mixing X drawing with opengl drawing.
If that was the case, AFAIK mixing in the same window is not good idea. As long as each X window is used either by opengl or by xlib, but not by both, all should be fine.

note that a child window is a “different” window from it’s parent and they both can use different apis without problem.

for that matter, using xlib to draw anything is usually a really bad idea, typically quite ugly and far from optimal.

I don’t think I’d go that far. If you want to render video, then no. You’d use the XVideo Xlib extension, or something vendor specific such as VDPAU. If you want the lowest level control, or something that supports remote rendering via X protocol most efficiently, Xlib may be your man.

However, to the original poster’s question, there are a number of modern GUI toolkits that’ll give you GUI widgets such as buttons with a clean interface without you having to reinvent the wheel. Qt for one. Also, in X11, windows can have child windows IIRC so you could potentially have a GL window with non-GL (e.g. GUI) children or vice versa, whether overlay or pop-up windows/widgets (though I’ve never had a need to try it). Don’t believe me? Run “xwininfo -root -children”.

And even if you really, really need your widgets to physically be drawn in the exact same X11 window as your OpenGL rendering (not just “look” like they are), there are plenty of OpenGL-based GUI toolkits out there to consider, such as AntTweakBar.

Or you can render your GL data to an XPixmap with OpenGL, and use Xlib to blast it up into a window with your widgets. Or you can blast your widgets into an XPixmap and composite them into your GL scene with OpenGL. Or… I’m sure there are other options.

But again, to the potential “significant loss of performance” concern, no way. Drawing GUI widgets is trivial regardless how you do it. The “significant loss of performance” is from having to sit there and wait for a user to react on the order of “seconds”, not “microseconds”. But alas, what do you do? Sometimes we need users to drive :slight_smile: Just because OpenGL can be accelerated does not mean that other rendering is not. It’s just what kind of acceleration you’re talking about.

Of course I didn’t mean only if he uses xlib directly, but also if he uses any modern GUI toolkit that is layered on top of xlib.
Same goes for opengl - “opengl drawing” includes not only directly using opengl yourself.

And by the way xlib is not that bad as you make it sound. For instance i use plain xlib+opengl when i am porting a game engine that was originally written for windows (and of course has it’s own UI system, like most game engines do). Well, actually not exactly plain xlib but with some extensions like Xrender for mouse cursors, Xrandr for switching video modes, etc.
But what’s the point of using “modern” toolkit in such case? It would only constitute a useless nasty bloat.

Another good quality that xlib has is that is it the greatest common divisor and is “guaranteed” to be present on “any” linux distribution and to work out of the box.
Whereas by using some random one from the countless “modern” toolkits you stick a dependency to your application and you must make provisions that whenever your application is installed, the necessary toolkits sill be available too.

Such generalizations are not good. It really depends on what you are doing.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.