Xlib-xcb programming questions, interested in creating/collaborating on tutorial maybe

Discussion in 'Programming/Scripts' started by DeeDeeK, Mar 3, 2018.

  1. DeeDeeK

    DeeDeeK New Member

    Hello. I'm new to HowtoForge and I really appreciate the tenor of most of the posts and simplicity of this site. I hope my post complies with the standards and guidelines!

    Question #1: What's the absolute fastest way to draw pixel accurate, filled, solid color rectangles into a window or pixmap without delving into overcomplicated libraries?

    I'm writing some graphics functions and I'd like to ONLY draw individual pixels or solid rectangles-nothing else-without having to get into some overly complicated library. Currently I'm using Xlib and xcb (#include Xlib-xcb.h) and simply call xcb_poly_fill_rectangle() and sometimes xcb_poly_point(). On my eight year old laptop with a 2nd gen i5, integrated graphics those calls fast enough to refresh the screen quickly if I've got < 200,000 rectangles. There's a very specific reason to use filled rectangles or points if the rectangles are only 1x1pixel. Any way to send a list of coordinates and have rectangles and points drawn faster than the xcb graphics primitives, which I can display in a window is what I'm after. Drawing with the CPU into shared memory pixmaps is slower, and I can't decipher the direct rendering interface, or even tell if it would be appropriate.

    Suggestions I've heard so far have mostly been about using OpenGl, using SDL, and various other very snazzy methods of rendering graphics, but the ONLY thing I wish to do is draw large numbers of solid, colored rectangles. There's no 3D math involved, it's not for realistic animation, it's absolutely NOT about anti-aliasing. In fact, it's about creating pixel based graphics. So a rectangle of width 10, for example, is precisely 10 pixels across and 10 pixels high, so there's no point in using Cairo or SDL (unless SDL has a function which will draw a list of rectangles of a specific color). Cairo is for line graphics, not pixels, so it's gotta be slower. SDL, doesn't seem exactly simple to me.

    My guess is the X.org's x server probably renders rectangles as fast as possible but it's hard to accept no other library offers a function which will take a window or pixmap id, a color, and a simple list of coordinates to draw rectangles at, and use the graphics hardware to render them. Which brings me to a question about creating a tutorial. I haven't found one on this site which delves into Xlib and/or xcb programming.

    Most advice is to use GTK+ or Qt. I don't know much about Qt but the GTK+ advice goes on to reccommend Cairo for drawing. GTK+ is a great library for creating GUIs. But it is very involved for someone who simply wants to put a window on the screen and draw directly into it, and to receive events from the mouse, keyboard, and to resize or close the window. Which leads to my second question.

    Question #2: Would people be in to a tutorial on using a very simple subset of Xlib-xcb and creating a library of simple functions, such as plot(int x, int y, int color) and how to draw offscreen then put it onscreen, as sort of pseudo-double-buffering?

    There's a lot of posts from hobbyists who once coded with Borland Turbo-C on DOS or maybe Windows, who ask about graphics.h, which allowed them to set the graphics mode and draw graphics primitives or individual pixels. The answers to their questions are always basically that it's not simple anymore. I've created a small library of data types and very simple windows I'd be happy to share, along with the information I used, and where to find that information. I'm totally inexpert, just a hobbyist, but I'm happy with the results and it's good enough to write simple games with or to create graphics to show the results of mathematics, or to animate shapes, draw lines and circles, etc. It's all about chunky low-res and simple colors. You can use all the colors you want and high resolution, but it's made for reproducing graphics as chunky as the old Atari 2600 if that's what you want. Anyhow I'd share it if people wanted, and I'd be even happier if anyone who knows more than me wanted to collaborate and correct or improve or add to the code I've got.

Share This Page