x11 guidance (slightly off-topic)

[Patrick <pabos glypsube org>]

While responding to the double-buffering thread a few other questions
surfaced in mind which I would appreciate clarification on. As I
mentioned I'm trying to design a multipurpose, singing, dancing,
all-around fun canvas that performs reliably fast under x. Can anybody:

 - Summarize what x standards/protocols/libraries etc. are relevant
today? By relevant I mean two things: (1) encouraged by x developers and
(2) primarily concerned with linux-style x window development (ie.
xrender, begin process of removing crusty legacy stuff)

 - Any recommended practices, no-no's, etc. for x programming (most
tutorials I've found seem to start very basic and stay there)

 - How low I should go for the canvas (ie. x or stay in gdk)

And if you'll indulge me further:

 - What problems other existing canvas implementations have.


My own impression is that the core of x is being cleared as much as
possible and therefore:
- x fonts are dead (replaced by xft2 and fontconfig)
- xprint, x internationalization/accessibility efforts (whatever they
are) are dead?
- x color management (?)
- x input method? (gtk input methods extend these apart from x?)

As for x extensions my impression is as follows (kindly correct if these
are wrong):

- Xv extension
	- Puts and gets deal only with RGB-style windows (are all x drawables
limited to RGB-style buffers?) and translates behind the scenes from
other video colourspaces.

- Xft2 extension
	- New glyph transmission method which either depends on Xrender (ie.
for transparency), will depend on Xrender (ie. transparency added when
Xrender is finished) or coexists alongside Xrender (ie. as just the
glyph transfer portion).

- Xrender
	- Is the protocol extension and will be accessed through Xc and Xr
libraries similar to how Xlib is the library for the standard protocol.

- RandR
	- Rotate and Resize extension. My canvas will have to listen for these
events. (Although if it ignores them (esp. rotation orientation)
wouldn't they just appear as window resize requests?)

- Xinerma
	- Multiple screens in a continuous display.
	- Accurate color and physical sizing of a canvas crossing displays
would require proper gamma, color calibration, and dpi settings for each
monitor?
	- Beyond this I'm not sure what the phrase "Xinerma aware" which I've
heard used would mean. (Unless it means aware enough to try to avoid
displaying windows across screens and thus avoiding that problem?)

- Xcursor
	- If I want nice (alpha-blended) mouse cursors use this

- Dbe
	- Pixmaps are in video card memory and this allows the X server to
intelligently know about double-buffering and automatically alternate
between the two buffers with a function call (but it doesn't guarantee
that it will switch on the vblank signal)? (guess)
	- Note to self: Does GDK already do this for its windows? Check source
to see what its hiding. Turn if off.

- MIT_SHM
	- In the local case this is useful to share an image between client and
server without copying the image around in memory on the same machine.

- Xshape
	- Non-rectangular windows.
	- I'm not sure how useful this is for a canvas.

- GLX
	- OpenGL.
	- I've never used OpenGL (yet) but I'm curious about its x window
interactions (ie. is a window "locked" for OpenGL usage? can the window
drawable be used by other routines which composite on top? does OpenGL
notify when it changes the display or this the application writer's
responsibility? etc.)

- Xt
	- what is Xt? My recollection from reading is that it is a higher-level
wrapper on Xlib with more structured semantics?


Well, I've thrown out a few questions. I don't expect answers to them
all but if anybody has a little knowledge to share I'd be grateful.

Patrick