advice

["max reason" <maxreason maxreason com>]

 Greetings,

 And probably apologies for not posting these questions in the correct place.
 Feel free to point me to the correct place if appropriate.

 I have several related questions related to gtk, cairo, pango, freetype and
 the general problem of drawing 2D graphics and text into memory that can then
 either become an OpenGL texture, or be combined with an OpenGL texture.

 At the same time, and perhaps separately, I need to create or adopt and attach
 some kind of GUI system to my application, which is probably best described as
 a 3D simulation/vision/game engine/server.  Since my application is written in
 C (actually, C++ without classes, templates, overloading and other annoyances),
 GTK+ looks like it may be a good choice for the GUI system, especially if the
 cairo and pango packages are the best way to draw text [and line/fill graphics].

 So my questions are two-fold:

 #1: is the GTK+ + cairo + pango combo the best components to accomplish my goals?
 #2: is drawing text and graphics to memory with these tools "the fastest possible"?

 First, here are a few details about my application, to assure suggestions are
 compatible with my portability requirements.

 The application is written in C (and key assembly language).
 The application assumes core OpenGL v3.20 and GLSL v1.50 (so far).
 The application runs on Linux and Windoze now, and hopefully someday on MAC.
 The application creates displays/windows/etc via low-level win32/wgl : xlib/glx.
 A few key routines are in 32-bit SIMD-SSE3+ assembly and 64-bit SIMD-SSE3+ assembly.

 The most important points are probably C-language and multiple-OS (linux/win32),
 plus ability to compile 32-bit mode and 64-bit mode variants.

 -----

 Another point I worry about is... event management.  Currently my application
 operates the win32/xlib event queue, converts those events into a uniform/portable
 set of messages that are compatible with the general purpose messages my application
 created to support general inter-process and client-server control and communication.
 I would hope GTK+ doesn't [need to] steal all system events and thereby wreck the
 already implemented scheme.  Hopefully one or the other can pass "irrelevant" events
 to the other, or some such arrangement, to prevent a "fight for control" that often
 happens in GUI systems.  I have no experience with GTK+ yet, so I have no idea.

 One possible way to evade this problem - maybe (you tell me) - is to place all
 GUI elements in a separate window, perhaps even a borderless transparent window
 that overlays a portion of the main 3D application window (and becomes more and
 more transparent the further the mouse moves from the GUI window/elements/widgets).
 Unfortunately, I suspect this might be less-than-optimal, because often the desired
 behavior when the mouse/pointer is over the GUI portion is to send mouse messages
 to the GUI, but send keyboard and joystick/game-controller messages to my 3D app.

 That's probably enough about GUI to establish a clear context for GTK+ gurus.

 -----

 My requirements and desires for drawing text and line/fill graphics are:

 #1: fast, faster, fastest and beyond fastest.
 #2: display clean sharp antialiased text; support bold, italic, etc.
 #3: display international text, including beyond first 65535 characters.
 #4: display as many proportional fonts as possible (TrueType, OpenType, etc).
 #5: prefer ability to draw directly into system memory (then copy onto texture).

 The primary reason for #1 is, one important focus of this 3D application is
 "procedurally generated content".  Therefore, in many situations, text string
 images will be applied to textures "on the fly", which means, between frames,
 which happen 60 times per second (15 to 120 per second range, usually 60 or 30).
 Therefore, drawing throughput needs to be fast, faster, fastest to avoid slowing
 or stuttering the display of frames.  I will offload some processes onto other
 CPU-cores (when they exist on a system), but this application needs to perform
 enormous loads of computations (on all CPU cores, and on GPU via GPGPU too),
 so making every process fast is crucial.

 I had heard (somewhere long ago, can't remember where) that freetype drawing to
 memory was "as fast as it gets".  But I also heard complaints about its speed.
 So I don't know the facts.  I am certainly willing have the application perform
 any necessary processes to speed operation from frame to frame.  For example,
 when a new font/size/style is created, the application can create a string with
 all characters in it - in the hope this makes the font package cache characters
 and characteristics before character strings are rendered to memory and textures.

 However, as far as I know, maybe GTK+/cairo/pango contain freetype!  Inform me.
 Also, if anyone has written GPU-shader routines that draw proportional font/text
 onto textures... that's probably even better (somehow, I'm guessing "not yet").

 -----

 I tried to make a short cairo+pango application work, but had no success due to
 dependency issues.  For some reason, none of the references I've found to date
 specify what .h files are needed, what .lib files are needed, what .dll files
 are needed, and what else might be needed too.  So I'd very much appreciate a
 paragraph called "cairo + pango dependencies for dummies", so I can compile a
 few trivial examples to get my feet wet.

 It occurs to me that perhaps all these dependency issues become easier with the
 GTK+ package (which presumably includes cairo and pango in its ZIP file), but
 until I determine GTK+ satisfies all my GUI requirements, I was trying to avoid
 GTK+ until then.

 -----

 I will greatly appreciate any advice you can give.  One final tip about me and
 my modus-operandi.  I prefer to program to the lowest-level possible, and not
 depend upon layers upon layers of "helper stuff".  I would be completely happy
 to write OS-specific versions of these text and line/fill graphics subsystems,
 except my impression is --- they will be much slower, because no options are
 available to draw directly into an application memory buffer that I can then
 tell OpenGL to directly overlay or transparency-merge onto an already existing
 OpenGL texture in GPU memory.  However, if I'm wrong about this - pipe up!  :-)

 Thanks in advance,

 Max