Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Like the title says, I'm looking for a library that's platform-agnostic and lightweight, for the purpose of displaying buttons, slider bars, check boxes, etc. in OpenGL. Ideally, something that is not directly coupled with OpenGL is best (ie. so that I may replace the rendering with DirectX if need be).
My 'ideal' library would have an event system that supports callbacks or something similar. This is a nice-to-have, but not absolutely required.
I looked into Qt and wxWidgets and both seem very heavy. CEGUI looks like a mess of code. Most other libraries I seen are GLUT based.
There's Dear IMGUI
https://github.com/ocornut/imgui
It's completely graphics API agnostic. It just builds vertices. Its up to you to render them.
There's also nuklear inspired by Dear ImGUI.
You might want to have a look at a game engine such as Irrlicht which provides OpenGL, DirectX and Software renderers and supports a 2D GUI System with Buttons, Lists, Edit boxes. See the feature page to learn more about its capabilities and the user interface sample to try this specific UI feature.
Irrlicht is open source and works on many platforms. From the feature page it supports:
Windows 98, ME, NT 4, 2000, XP, XP64, Vista, CE
Linux
OSX
Sun Solaris/SPARC
All platforms using SDL
Neither wxWidgets nor Qt draw in OpenGL; they don't use OpenGL rendering commands to draw. They allow you to create OpenGL windows, but the regular GUI controls (buttons, lists, etc) are not drawing through OpenGL. They're drawn through the native drawing mechanism of your platform of choice.
You are generally not going to find very many standalone GUI libraries that actually do their rendering in OpenGL. The only one I know of is CeGUI, which fits all of your requirements but you dismissed as being "a mess of code." Everything else is generally going to be "heavyweight", because it's part of a game engine.
Now, if you're not looking for something that actually draws using OpenGL commands, but is simply something that you can use alongside an OpenGL window, then things open up somewhat. However, your dismissal of wxWidgets as being "very heavy" is disconcerting, because GUI libraries aren't really going to get much lighter weight than that. A good GUI system requires a lot of stuff.
The smallest cross-platform GUI library that supports making an OpenGL window is probably FLTK. And even that's pretty big.
Related
I am interested in making a game trainer but I stumbled over the question of making a menu which the player can choose from. I am using C++ and my target client is windows based.
I searched around and people mostly use DirectX and hook into the game to draw (A little bit like the discord overlay) but I find it extremely difficult to use DirectX.
Here is an example I found:
I really like the way the SFML library draws but I can't seem to find any APIs which support that ease of drawing.
I once did manage to make a menu in C# by using System.Drawing to draw an external overlay which I could draw to using C#'s brush API, however I prefer to write in C++ as I feel I can do more in that language.
My question is:
Is the a way I could use something like the System.Drawing/SFML API to draw an overlay over another window in C++ (Which would be accessible in a console application)?
Is it easily portable (As a DLL or even including a header)? (Most of the solutions I have seen are not portable and/or widely supported)
Check out Qt for drawing images, text, etc.
http://doc.qt.io/qt-5/qtwidgets-painting-basicdrawing-example.html
It is widely supported, and also cross-platform
You can create a transparent window and use setWindowFlags(Qt::WindowStaysOnTopHint);
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How do normally people make GUI programs with a mix of windowed GUI and 3D rendering? i.e. SolidWorks
More specifically:
It seems that OpenGL is tailored more towards rendering and creating 3D Objects/Worlds which would be more like a game, for lack of a better description. So for example If I wanted to create a GUI (i.e. like MATLAB) using OpenGL I would have to program all character information for text editing, buttons etc. from scratch, which seems ridiculous.
So if I wanted to create these windows I would use a builder like Qt with all it's functionality but then I'm limited, if I wanted to create a fancy 3D model in Qt then I'm forced to use all the Qt functions which aren't as good as OpenGl right? (Also how does Wayland fit into this picture?)
What makes you think you can't mix and match things? Also you suffer from misconceptions about what OpenGL, Qt and Wayland are. In general the question is far too broad to answer satisfyingly. I already gave a lengthy explanation here: https://stackoverflow.com/a/18006486/524368
In short terms:
Wayland: A protocol to send framebuffer handles and user input and interaction events between procsses (nothing more)
Wayland compositor: creates framebuffers and gives them to clients using the Wayland protocol
Wayland client: draws to the framebuffers by whatever method they like
Westion: A Wayland compositor that creates framebuffers as on-screen windows for clients to draw to
X11: A graphics and user input server protocol; clients can connect to a X11 server and send it X11 drawing commands that the server executes toward a framebuffer (drawable in X11 terms). Traditionally X11 draws directly to the screen, but given the right X11 server (Xwayland) can draw to a Wayland framebuffer as well. Also X11 multiplexes user input (mouse, keyboard, joystick, and so on) to the connected clients.
X11 server: Implements the display side backend of a X11 system.
X11 client: Connects to a X11 server and sends drawing commands.
OpenGL: A framebuffer oriented drawing API. Essentially OpenGL provides methods to efficiently draw points, lines and triangles to a framebuffer. The process of drawing can be either fixed function in a hardwired set of operations (old style OpenGL) or freely programmed (modern, shader based OpenGL). OpenGL drawing commands can be sent to a X11 server that implements GLX; in that case the OpenGL commands are executed by the X11 server and the clients just sends the server a stream of commands. However often OpenGL commands are executed directly by the process using the OpenGL API, going directly to the GPU which processes them into pixels in a framebuffer.
Toolkits like Qt or GTK: Provide abstractions for the creation of user interfaces. Windows and widgets are logical structures that organize the contents of a framebuffer. User input is processed in a event system which the programmer can use to control the facilities provided by the toolkit. User interface elements are drawn by whatever means are available to the toolkit. This can be either drawing methods native to the graphics system being used (X11 drawing commands) or if there is no native set drawing commands, as in Wayland, with whatever fits the bill. So OpenGL is a viable option (and is used as such) by Qt do draw its userinterface elements if the runtime environment of the process is well suited for this.
How do normally people make GUI programs with a mix of windowed GUI and 3D rendering? i.e. SolidWorks
They use a toolkit like Qt and where 3D stuff must be drawn OpenGL (or a similar API) is being used.
It seems that OpenGL is tailored more towards rendering and creating 3D Objects/Worlds which would be more like a game, for lack of a better description.
OpenGL just draws points, lines and triangles.
There are no "scenes" or "worlds" in OpenGL. Everything that looks like a scene or a game environment happens due to the program logic using OpenGL in a way, that the outcome looks like it.
Also OpenGL doesn't do windows, it doesn't to user input. Use a GUI toolkit for the whole widget business and use OpenGL to draw your scene.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
I was wondering what is the difference between the windows that will render images on the screen (such as SDL, SFML or OpenGL) and the classic GUI window (with the gray background by default) where you can implement buttons like in Qt for C++ or AWT/Swing in Java?
What is going on in the background code? Are they the same type? Is there a rendering layer over the graphics window allowing to display such images?
Well first of all they are different APIs. SDL and SFML are libraries directed at making games and quite possibly other applications. OpenGL is a graphics API, it is not a full suite of libraries.
Note also that SFML pretty much uses OpenGL to render to the window. The actual window its self is created via platform specific functions. The Win32 API is used for windows and the X11 Window System is generally used on Linux.
The "classic GUI window" is pretty much the platform specific APIs. The differences in background code is really just defined by the purpose of the API. Note that in the end of the line Qt/SFML/SDL all go down to the platform specific API. OpenGL even requires you to interface with the platform specific API. SFML/SDL/QT essentially do the lower level work for you.
I hope I gave what you are looking for as this question really has a wide range of answers.
Besides Qt, GTK, wxWidgets... What are the recommendations for a cross platform, open source GUI framework library that works with OpenGL?
Its not quite a GUI framework. But GLFW is good for an OpenGL window with some extra features like keyboard and joystick handling.
I found the other framework I was looking for. It is SFML. I only used it briefly but I do remember liking it very much. It does contain a lot of nice extras going a step further than GLFW. If I recall correctly the documentation was stellar.
For a full featured cross-platform GUI framework I think you would be hard pressed to beat QT, GTK, or wx.
I'm not sure, but at a guess, the other framework mfperzel was trying to think of might have been fltk (the "fast light tool kit"). Where glfw is mostly an OpenGL window with some ability to read the mouse and keyboard, fltk is a GUI framework that supports OpenGL (but as the name implies it's still quite a bit smaller and faster than most GUI frameworks). I haven't tried it yet, but there's a new GUI builder program for it (FLUID) that looks fairly promising as well. One warning though: FLTK uses its own widgets, which tend to look at least a little foreign to most users.