Equivalent of windows gdi regions in linux - windows

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.

Related

2D graphics without OpenGL / DirectX as for a GUI Toolkit

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.

Procedurally generated GUI

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

What's the fastest way to draw to a HWND on modern Windows?

When I last did this you would use DirectDraw to blit to a hardware surface, or even directly map it and draw directly.
What is the recommended method to do this today? Use Direct3D 10/11 and do the same?
Edit: To clarify my question, I want to do some software rasterization and therefore need a fast way to blit pixel data directly to the display.
I would suggest to use Direct2D which is meant for desktop applications these days. Quote:
Purpose
Direct2D is a hardware-accelerated, immediate-mode, 2-D graphics API
that provides high performance and high-quality rendering for 2-D
geometry, bitmaps, and text. The Direct2D API is designed to
interoperate well with GDI, GDI+, and Direct3D.
Requirements: Vista and higher as well as the respective server versions (if that is needed).

Are Xlib's graphic functions fast?

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.

Detecting hardware overlay

How can I detect if a given window has an hardware overlay surface? (like MediaPlayer, WinDVD, VLC,...)
Overlay surfaces are not related to any system window, in principle, they are surfaces to be "composed" with the video framebuffer (or the primary display surface). What you can detect is (depending on your API) if the hardware supports overlays, how many planes, supported formats (YUV, etc) and so on. This can be done from DX and OpenGL, for example.
Many tasks done in the past with overlays can be done now with the composition support of modern window managers, e.g: compiz, DWM in Vista, Quartz in OSX. In fact, I think programming with raw overlay surfaces is discouraged since WMs are providing such composition facilities for application developers.

Resources