Re Wayland: Regardless of whether you use Xlib or XCB, your application will use the X protocol, which means it won't run natively on a Wayland desktop but only via Xwayland. Real GUI toolkits nowadays have separate backends for X and Wayland, defaulting to the Wayland backend when run on a Wayland desktop. So while XCB is better than Xlib, you really shouldn't use either.
Re offscreen rendering: This is orthogonal to double buffering but refers to the way modern compositing desktops (including Wayland) work. The application renders the window image into an offscreen surface which is then handed off to the compositor, which blits it to the screen.
Re GPU rendering: You can draw rectangles on a surface on the CPU by simply setting pixel color values in a loop, or you can draw them on the GPU by sending a list of rectangles and have the GPU do the rasterization of the rectangles. Toolkits like Qt or Gtk can do both, depending on the backend that is selected, and will typically default to GPU rendering on modern desktops.
I fail to see the reference to be honest. I remember the term from OpenGL, when I rendered something to a framebuffer (actually its attachmets) and then applied to the current framebuffer. It helped me to do effects like night vision. Does using offscreen rendering imply using OpenGL?
Does GPU rendering mean that I have to involve OpenGL/Vulkan?
Re offscreen rendering: This is orthogonal to double buffering but refers to the way modern compositing desktops (including Wayland) work. The application renders the window image into an offscreen surface which is then handed off to the compositor, which blits it to the screen.
Re GPU rendering: You can draw rectangles on a surface on the CPU by simply setting pixel color values in a loop, or you can draw them on the GPU by sending a list of rectangles and have the GPU do the rasterization of the rectangles. Toolkits like Qt or Gtk can do both, depending on the backend that is selected, and will typically default to GPU rendering on modern desktops.