I am wondering how to create some 2D graphics without using OpenGL or DirectX. Like, what do e.g. Qt or GTK use, to draw what is basically colored rectangles (and text)?
I know that with KDE 5 and Gnome 3 there were some complains that now OpenGL is required (for certain effects including 3D stuff like the desktop cube that was trendy for a while). So apparently something simpler was used before, yet I can't find out what. Here the answers are basically: OpenGL or SDL …
Well the most basic way you have to draw a window on linux is to use Xlib or Win32 on windows. These are very basic window drawing APIs that also handle events. But it would probably be a lot of work to use them on their own.
SDL, SFML, or OpenGL are probably better options in most cases, since window rendering protocols can draw rectangles and images but lack a lot of QoL features that make your life as a dev easier. Maybe if you are looking for the absolute best performance Xlib (or wayland) would be the way to go, but if you are looking for a simple way to code a GUI application it's probably a bad idea.
If you want a great and easy to use GuI to do menus and stuffs, dear ImGui is very impressive and easy to use, and can run in a variety of rendering surfaces including SDL and DirectX
Also this answer could help you, it's seems a bit close :
Does OpenGL use Xlib to draw windows and render things, or is it the other way around?
You'll notice that at the end they talk of other ways to draw windows which are AGG and Cairo. It's a bit of a wall text but a greatly detailed answer.
Related
I've developed an interactive audio visualization engine. I need to make its GUI scalable to various screen sizes with various PPIs (this includes both very large screens and mobile devices). Designer simply sent me a PSD with graphical representation of supported widgets. I'm exporting these into PNGs. The problem is that those bitmaps are of course not scalable and looks ugly.
I've thought about several ways how to achieve resolution and PPI independent GUI:
Export PNGs with various sizes and select the current set on runtime (waste of space simply for storing bitmaps in various resolutions)
Use scale 9 images only (no fancy stuff)
Use SVG (not supported by rendering APIs, could use smth like nanovg for OpenGL but what to do with raw framebuffer then?, also performance problems and too much complexity for what I need)
I came to an idea to pregenerate bitmaps at runtime for specific device once and use them afterwards. Are there any specific libraries for that and maybe already available themes which I could employ for now? I imagine tool could work similarly to how cairo graphics library or javascript canvas work by reading command list and outputting a bitmap. Any other ideas?
One possible solution is this:
CPlayer is a procedural graphics player with an IMGUI toolkit. It can
be used for anything from quick demos, prototyping graphics apps, to
full-fledged apps and games.
http://luapower.com/cplayer.html
I've created a relatively simple tower defense game using c++ and SFML. I'm very interested in creating a nice gui overlay for it, ie hud, menus, etc. I know there are a lot of gui libraries out there, but I would like to make my own (for learning purposes.
I'm very familiar with working with graphics, but I'm not as familiar with GUI systems (I just render my frames, and don't worry about widgets, title bars, etc.).
Are there any good articles out there, or perhaps suggestions anyone has regarding how to layout such an interface?
There are a couple ways I know of (at least for Java) to get a nice HUD in your game. One method is to have a separate 3D world with the UI elements placed directly in front of the camera, then overlay that camera's view over the main view. This can be buggy at times, especially when you don't have a good color filter, or when you have a high number of objects being displayed. Another method is to look at a GUI library designed for this purpose (such as NiftyGUI for Java).
A quick Google search lead me to a listing on Wikipedia of many open-source GUI libraries you could use. There are many others out there, so you should probably do the Google search yourself, or look around on GitHub and SourceForge.
I sometimes use windows gdi regions for graphics drawing and invalidation/validation. For example the program http://www.maxerist.net/main/soft-for-win/tubicus (oss) was made using only regions (no bitmaps or off-screen buffer). The drawing was made with FillRgn and FrameRgn, invalidation and painting with InvalidateRgn and CombineRgn, every cell (see screenshot) is a simple region created with CreateEllipticRgn, CreatePolygonRgn and CombineRgn.
I have plans to port it to Linux. As I understood, there are many graphics libraries in Linux. Are there ones that support windows-like regions?
Thanks
You want to use The X Window System, a.k.a. X11, as your graphic platform. Its client library is called Xlib. The platform supports polygonal regions.
There are many libraries written on top of Xlib (Gtk, Qt, wxWindows and more) but you always can use the low-level Xlib API directly with any of them. Qt even supports elliptic regions. I don't know the details but I guess it's implemented on top of X11 polygonal regions.
Qt has a lot of options for painting, and using QPainter with QPainterPath objects might suit you well. (There are samples in the Qt distribution). You can combine (add/intersect/substact) paths.
The QGraphicsView framework is a good alternative too.
I am a absolutely new GUI programmer with very little experience (except some small apps in Java). I am considering writing a small app that needs simple 2D graphs. I don't know if I should use Xlib or cairo to do the plots.
Is Xlib's graphic components fast compared to, say, cairo? If cairo is written using Xlib, then the answer would obviously be yes, but I don't know if it is.
Xlib doesn't do any graphics itself. If you are talking about server graphics primitives, they are usually pretty fast these days, but they are also fairly limited (lines, rectangles, polygons, elipses, trapezoids; solid color fills) and tend not to get any special acceleration by the graphics drivers.
Honestly, you ought not program against Xlib or xcb directly. Instead, use a toolkit like Qt, GTK+ or FLTK (or wxWindows, or, or....). They provide a framework for building applications, as well as abstracting away the X details into an easy to use API.
Generally all of the the libraries which leverage Xlib to do their drawing do so in an optimized manner. You would have trouble matching the performance of say, scrolling on your own. You also have no widgets and a library which makes the simplest tasks thousand-line behemoths.
I remember my old Radeon graphics drivers which had a number of overlay effects or color filters (whatever they are called) that would render the screen in e.g. sepia tones or negative colors. My current NVIDIA card does not seem to have such a function so I wondered if it is possible to make my own for Vista.
I don't know if there is some way to hook into window's rendering engine or, alternatively, into NVIDIA's drivers to achieve this effect. While it would be cool to just be able to modify the color, it would be even better to modify the color based on its screen coordinates or perform other more varied functions. An example would be colors which are more desaturated the longer they are from the center of the screen.
I don't have a specific use scenario so I cannot provide much more information. Basically, I'm just curious if there is anything to work with in this area.
You could have a full-screen layered window on top of everything and passing through click events.. However that's hacky and slow compared to what could be done by getting a hook in the WDM renderer's DirectX context. However, so far it's not possible, as Microsoft does not provide any public interface into this.
The Flip 3D utility does this, though, but even there that functionality is not in the program, it's in the WDM DLL, called by ordinal (hidden/undocumented function, obviously, since it doesn't serve any other purpose). So pretty much another dead end, from where I haven't bothered to dig deeper.
On that front, the best we can do is wait for some kind of official API.