2012-02-19 Fast per-X-Window Texture Mapping
Xwins showing an emacs (left) and itself (right)
xwins - On a
more upbeat side than the I-miss-LISP woes, a new xwins
program I wrote couple of weeks ago to allow the manipulation (with a
Spaceball or whatever) of live X windows mapped onto textures in OpenGL
has turned out to be useful, especially for magnification, and is much
faster than the X-server to texture approach used in xvbftex
experiment from a while back. It's essentially a quick hack to test a few
- XCompositeRedirectWindow - render X windows as texture.
- Quaternions - finally an end to gimble lock.
- 3dconnexion controller lib - no longer using my old serial Spaceball driver.
- CPP-based list mixins - add Push/Pop/Extract/Count to an arbitrary structure.
Zooming with the spaceball is more entertaining than xmag,
especially when you point the application at its own output window.
The mapped Emacs window in the sample image is fully active, even in
its many recursing views. Adding the pointer tracking and input
xvbftex would yield yet another OpenGL window
As usual, though, implementing anything in GLUT runs into a wall before
long (crippled callbacks, and sadly, GLFW has the same problem), and
xwins become independent of that curséd subsystem a few days later.
2012-02-18 Single Inheritance in C
Implementing single inheritance in C is an interesting exercise, with a
number of approaches from the one used in the X widgets, to heavy
reliance on the C preprocessor for structure member copying, to using
obscure GCC options to allow the same thing through anonymous
-std=gnu99 -fplan9-extensions is pretty
convenient for this approach). Add to this a year-long break while
buried in Python coding, and the result is a deep disaffection with not
having easy containers in C, yet horror at what's required to write
such in STL-style code in C++.
(Oh, LISP, why have we forsaken thee?)
Reinvention of containers is basically a time-sucking detour, but a
certain popular container library for C instantly suicides upon memory
exhaustion, and another doesn't but has a really annoying usage model
(from my utterly subjective perspective). Wanting to base a set of
containers upon an incomplete inheritance model is a bit like creating
three new problems, all squarely in the way of starting the Real Work.
An interesting, simple abuse of CPP (used in xwins, q.v.) yields a
mixin-like approach to ornamenting arbitrary data structures with fifo
or list-like attributes and methods.
of object types has been dropped in favor of focussing on stressing
inter-Zone synchronization purely through Z protocol. Synchronizing
between two Zones at versions N and N+1 is much more robust than
updating types within a given Zone on the fly. Since either approach
allows a developer to maintain an existing session during the
upgrade-or-switchover, only a performance grail lies on the dynamic
loading path, rarely a wise objective when prototyping. Simple dynamic
loading, on the other hand, is a nearly free side effect of the in-dev
inheritance model, lacking only C++-like namespaces to be tidy.
If it's too untidy, I may fall back to static inheritance.
2011-01-22 In C, Reloaded
There's been a hiatus of a several years. In that time, I've
experienced C++ syntax changes that invalidated large chunks of code,
been blocked in sharing programs due to C++'s lower portability, and
seen the fundamental truth in the Linux kernel developer attitude that
C++ is simply a poor solution to demands for long-term development where
the eventual deployments sites' compiler versions can't be controlled.
This has been a troubling realization, since despite C++'s ridiculously
complicated syntax, it offers a number of nice features I've been loath
But it's time.
So I've been exploring rewriting the whole thing in an object-oriented
C style, which provides a perfect opportunity to try integrating
dynamic loading, which although perfectly usable in C++, wasn't added to
the older Z code due to coding paradigm inertia. I'd really like to
see a server than can dynamically change the type of objects, so that a
developer can often inject improvements without leaving the 3D
environment. If a restart is required, it would be nice for the client
library to offer transparent reconnect to the Zone (Z server) after
the restart, if the Zone succeeded in carrying its state forward through
2004-12-29 C++ N-Tree[trapezoidal] Class
Currently entangled in the process of writing an STL-like NTree class.
It's a bit frustrating that although there are reasonable overviews of
writing STL extensions, it seems to be nearly impossible to dig up a good
canonical example upon which to base a new template. Grrr. Regardless
of the trauma factor however, moving the implementation of the Zones'
tree structures into a generic class allows the mechanism to be tested in
relative isolation, which is clearly worthwhile.
Part of the quirkiness of the implementation I'm working has to do with
the search for LISP-like tree instantiation. With some clever use of +
and an auxilliary class, one should be able to generate reasonably
efficient code for creating trees with code similar to that used for
static initializations. In the example below, copies are made of the
original nodes by the + and / operators, with this floating copy, once
linked together, assigned to the tree.
It doesn't help, of course, that C++ wants all the happy temporaries in
such an expression to be constant, dramatically interfering with
the whole goal of linking them without generating gobs of sub-copies.
typedef NtreeNode_t<std::string> N;
N tree = (N("a1") / (N("b1") / (N("c1") +
N("c2") ) +
N("b2") / (N("d1") +
2004-01-21 Morphable X Servers
xvfbtex showing the xgltex server mapped onto an animated
sinusoidal surface. Xterm shows ps output
Substantial tweaking has produced a version of xvfbtex
with full tracking of the textured X server's cursor by user control of
the pointer across the scene.
Basically this means that when you move the mouse across a scene of
objects, your path across the object with an X server framebuffer
textured across the side will be tracked by that X server's pointer.
Currently pointer tracking is a special case, and has not yet been
encapsulated in a form suitable for reuse, but that encapsulation will
provide, among other things, a straightforward approach to interactive
painting onto 3d surfaces.
2003-10 Ah, threads.
the threaded life project)
I knew that writing the classic life cellular automaton as a orgy of
one per cell, plus threads for input and display,
would expose some limitations; that was the point. But I was surprised
to discover just how much misinformation is out there about limits on
the maximum number of threads in a process. So, to help anyone else
trying to run a few thousand threads in one program: the cumulative
stack size in all your threads is probably the problem. You can test
this as easily as using the ulimit shell builtin to reduce your
default stack size, and then seeing if suddenly your program can create
more threads than before. The same reduction can be coded using
With this method, I reduced the stack sizes for the cell threads in the
test code from 1 MB to 1 KB for all but 3 threads, and now it works
fine at 7103 threads instead of the earlier 234. The
file /proc/sys/kernel/threads-max on my machine contains the
value of 14336, suggesting a maximum of about twice what I'm seeing,
but I don't see a need for anywhere near even what my testcase is using
(although, I wonder if you could overlap the stacks if your threads
used no variables or function calls...hehe). Good luck :-)
Cogito ergo spud (I think therefore I yam).
Your browser's CSS support is broken.