graphics - Does OpenGL use Xlib to draw windows and render things, or is it the other way around? -

i want render fonts , lines on window using either opengl or xlib, i'd know 1 "more fundamental".

using xlib interface can render such things (which found here):

// gcc x_1.c -o x_1 -lx11 && ./x_1  #include <stdio.h> #include <x11/xlib.h>  // program draws red line , text in chosen font. display *display; window  window; xsetwindowattributes attributes; xgcvalues gr_values; xfontstruct *fontinfo; gc gr_context; visual *visual; int depth; int screen; xevent event; xcolor    color, dummy;  int main() {      display = xopendisplay(null);      screen = defaultscreen(display);      visual = defaultvisual(display,screen);      depth  = defaultdepth(display,screen);      attributes.background_pixel = xwhitepixel(display,screen);       window = xcreatewindow( display,xrootwindow(display,screen),                             200, 200, 350, 200, 5, depth,  inputoutput,                             visual ,cwbackpixel, &attributes);      xselectinput(display,window,exposuremask | keypressmask) ;      fontinfo = xloadqueryfont(display,"6x10");       xallocnamedcolor(display, defaultcolormap(display, screen),"red",                       &color,&dummy);       gr_values.font = fontinfo->fid;      gr_values.foreground = color.pixel;      gr_context=xcreategc(display,window,gcfont+gcforeground, &gr_values);      xflush(display);      xmapwindow(display,window);      xflush(display);       while(1){         xnextevent(display,&event);          switch(event.type){         case expose:              xdrawline(display,window,gr_context,0,0, 100, 100);              xdrawstring(display,window,gr_context,100,100,"hello",5);              break;         case keypress:              xclosedisplay(display);              return 1;          }      }      return 0; } 

now, can accomplish exact same thing using pure opengl code, raises few questions.

does opengl use xlib display windows , render fonts/geometric primitives? or other way around?

which 1 should use if want more "low-level" control on rendering , display?

---

edit:

my target application barebones text editor render bitmap fonts, have 255 colors, , software rendering (ie. assume no gpu present).

i tried cairo/pango, sdl2, gtk , qt, they're slow , unresponsive compared pure xlib.

warning: wall of text coming in!

@sourcejedi gave answer there inaccuracies in – not hurtful, may confusing.

first , foremost opengl , xlib orthogonal each other. neither depends on other 1 , can use them independently. there is dependency on xlib glx (which is, why can't ditch xlib in favor of xcb if want glx), surface area of dependency small enough, can use xcb part , use xlib-on-xcb wrapper few parts have use glx. i've dropped few acronyms here, let's categorize them first:

xlib & xcb both libraries implement client side of x11 protocol. technically talk x11 server without them, implementing protocol "yourself" (in fact there ongoing effort autogenerate haskell code same specification files used generate xcb code). x11 transferred on sockets, if can somehow transfer socket , internal state between bindings can mix , match bindings, if you're careful tread.

opengl pure low level (low level in sense of primitives offers: points, lines , triangles) drawing tool, , there no concept of "windows" in it. introduction of framebuffer objects, in principle can create headless opengl context , operate entirely within bounds of self-managed image surfaces. (but not always) want drawing(s) visible on display. that's window system interface (wsi) comes play. opengl , thereby whole support structure around quite old though, not lot of thought has been put whole wsi business, led rather, well… there's no cleanly defined interface @ all, far, happens circumstancial. usual way "here i've got preexisting image surface curtsey of display system, can haz opengl on please?" brings rather ad-hoc window system apis opengl. glx x11 , wgl win32; apple whole chapter of own…

glx 2 things: first it's x11 extension, i.e. uses x11 transport create channel new set of commands in x11 server. these commands opengl functions specified versions 1.1 through 2.1 (glx has not yet been specified 3.x onward). in regard glx places opengl implementation on x11 server side , glx opcodes used remote procedure call toward opengl context running server side. second glx client side implementation that's housed in libgl.so opengl api access library.

in addition glx implements few "convenience" functions, creating opengl display-listed rasterop "fonts" x11 server side fonts; works old-and-busted bitmap fonts have been around x11 core since ever. doesn't antialias , don't particularly on low pixel density displays (if have high pixel density output device can away without antialiasing , high resolution bitmap fonts excellent, case in point: laser printers). wgl followed glx's lead , did same windows bitmap fonts. that's "kind-of" font rendering support that's built directly opengl ecosystem. it's pretty useless outside 7-bit printable ascii set. , totally lacks layout engine format text (left, right, center aligned, justified or whatever). , relies on display lists , opengl raster ops have caveats "the whole thing won't go work if starting position of first character happens lie outside viewport". don't bother trying use it.

with glx can take existing x11 window , send x11 server commands set window use opengl. glx can send x11 server commands ask create opengl context. opengl context not tied particular x11 drawable. can attach , detach freely, long drawable you're intending attach compatible context (i.e. has been configured particular framebuffer format, context expects main framebuffer). when make opengl calls, glx wraps them opcodes , sends them on socket connection x11 server they're executed.

of course de-/serialization incurs non insignificant execution cost, hence special mode called "direct context" introduced, glx/x11-server combo used setup opengl context , making current on x11 drawables , rest program working directly against opengl implementation, thereby avoiding serialization , getting direct access address space bulk data objects (textures, buffer objects, etc.) reside. why in x11 based environment can find instances of opengl implementation same direct connection context present in 2 processes: x11 server , client using it.

as mentioned above xlib, xcb & co client side implementations of x11 protocol. server side of x11 provides basic set of graphics functions. x11 core has limited bitmap font drawing capabilities, along functions drawing points, lines, arcs, (rounded) rectangles, circles , polygons. drawing , filling happens solid pen or hatching pattern; there's no interpolation or gradients going on. depending on kind of image want draw rather limiting. between years 2000 2010 wanted draw colourful uis lots of gradients , fancy borders , whatnot (personally never liked those), in past years semi-/flat ui designs have become trend , draw rather x11 core (sans antialiased text). people wanted able draw gradients x11 side, xrender extension introduced, gives 2d equivalent of opengl's gl_triangles primitive, without shaders, textures , illumination; color interpolation, gradients , antialiasing though. sidetrack xft library (important, that's library, not x11 server thing), created piggybacks on xrender load bunch of client side rasterized font glyphs server onto drawable "antialiased" text. that's drawing capabilities of x11 server. how these drawing capabilities implemented in x11 server unspecified , depend on implementation , more importantly on device dependent x code (ddx) aka x graphics driver! done purely in software (often case, through server side component based on pixman render library), gpu accelerated or based on server side part of used opengl implementation (glamor).

which 1 should use if want more "low-level" control on rendering , display?

that depends entirely on target application.

if you're aiming doing that's not doing lot of graphics-graphics (text editor, chat program or so) , you're okay being tied x11 x11 through xlib or xcb. importantly x11 gives pretends half-way reasonable text drawing functions @ least work in predictable ways.

opengl proper choice if you're aiming doing graphics-graphics work (image manipulation, cad, desktop publishing, web browsers), means you're "on own" goes beyond points, lines , triangles.

these days it's practically given gpu present. 10 years ago, not much, ui toolkits , graphics backends developed (and we're still using those) of work purely in software, on cpu , transfer final image display device. reasonable then. , if ultimate goal reproducible, high quality graphics still is, because gpus cut lot of corners performance , don't behave identically (opengl demands rendering results of same chain of operations within same context 1:1 matches, change 1 bit , bets off).

the 3 rendering libraries can find these days on modern linux(!) system (not x11 based in general!) , can used "stand-alone" cairo, anti-grain-geometry (agg) , pixman. cairo used gdk/gtk+ based programs, pixman in x11 server (but can use in program, too). agg none toolkit's primary graphics kit in particular, used number of programs , libraries (most notably plotting, matplotlib). 1 must not forget "raster" graphics engine in qt, can used within qt within qpainter (so stand-alone if program uses qt, can't used without qt).

when comes agg vs. cairo biggest selling point cairo is, got pure c binding. unfortunately cairo not fast renderer (it made huge progress in past 10 years). it's eating dust of agg, faster , (ironically) produces better quality; unfortunately agg c++ library, use you're bound use c++, downside. principle developer of agg sadly passed away few years ago, stalled development time, it's been picked community again.