2002-09-13 18:23:58 CDT (Sep Fri) 1031959438 Running ------- For help: ./XGLTEX --help You'd probably need xvfdtex and some demo viewer, like xvfdtex. An example command would be: ./XGLTEX -x 1024 -y 768 -z 3 -c 8 -p 24 :1 ...sets up a buffer xvfdtex currently knows how to read. Note that performance suffers somewhat for x and y dimensions which aren't powers of two, particularly for such x dimensions. Look for a line in the output about 11 lines from the end resembling: "shared mem: 1188298793 shmid, 790528 bytes, address 0x401ad000" and use the shmid (in this case 1188298793) as the arg to xvfdtex. The display number here is the :1 (your main X server is usually using :0), and the next two arguments are the x and y dimensions ./xvfbtex 1188298793 :1 1024 768 Now, in a xterm or the like on your main Xserver, execute: export DISPLAY=:1.0 The xvfdtex program will copy across your X keymap, X modifier map, and X pointer (mouse) map. Otherwise, you have to run something like "xmodmap xvfdtex.pke.modmap". And now all commands you run in that terminal will show up in the XGLTEX server. Be aware that if you disconnect all the Xclients you've started, XGLTEX does a reset and that will incidentally prevent new clients from connecting. So, for example, setting the background with xsetroot or something works fine, but unless some other client is keeping the Xserver session alive, xsetroot's exit will immediately cut you off. Furthermore, XGLTEX still tends to leave shmem segment allocated, especially if killed. Under Linux, one can use the ipcs(1) command to find them, and "ipcrm -m " to remove them. BANDWIDTH --------- So far I've had a some frustration in that the AGP bus just doesn't seem to handle pushing 3 MB textures at a decent framerate. What's needed is an X server that uses the GLtexture formats on its framebuffer, and also tracks which subareas have been modified, so that just these can be stuffed down AGP's throat instead of the whole image each update. Basically this would mean that the Xserver would maintain the framebuffer and a list of areas which had recently changed, and the VR viewer sharing that framebuffer via memory-mapping would find the list of changed areas in shared memory just after the framebuffer itself - some synchronization may be necessary, unfortunately, for this, something I was trying to avoid. An approach using an array of bits for a tile of little 16x16 rectangles across the framebuffer might solve that problem though, since the client could just compare a cached copy versus the Xserver's evolving recent-change map. The client could then update its GL texture using glTexSubImage2D on just the changed parts. I really wish I had an SGI, here, since apparently they can map textures directly from main memory, and none of these contortions would be necessary. glTexSubImage2D has the additional unpleasant quirk of not allowing true source-subimage to target-position copying, instead assuming the source is to be copied in its entirety. This is an issue when trying to update subsegments of scanlines, in particular when trying to omit copying of the blank area on the right side of the framebuffer texture when using widths which aren't powers of 2. [pixel type] The ability to handle more of the documented pixel data types for glTexSubImage2D(3G), especially the one- and two-byte RGB(A) types, would be helpful in reducing bandwidth consumption. The first to implement would probably be the GL_UNSIGNED_SHORT_5_6_5 and GL_UNSIGNED_BYTE_3_3_2. Ideally all should be supported. [pixel format] Texture formats, as per the glTexSubImage2D(3G) manual page, used by XGLTEX should include GL_RGBA, GL_RGB, and probably GL_LUMINANCE for the greyscale/monochrome buffers. Obviously the attached viewing program can treat the data differently, such as treating GL_LUMINANCE info as GL_RED. GL_LUMINANCE_ALPHA, GL_DEPTH_COMPONENT, INPUT ----- Currently, mouse coordinates withing the xvfdtex window are used directly to determine the XGLTEX server's mouse position. Later, gluUnproject() will be the function of choice for determining coordinates within the target object's frame of reference. This will allow full pointer use even when the XGLTEX texture is mapping onto a surface which is non-planar, or which not normal section of the viewing frustum. URLs - note: this section is still mostly hypothetical ---- To specify the texture to use, where a shmem screen is targeted, use the general form: xserver://hostname:dpy.screen/shmem ...while noting that will obviously have to be the local host if shared mem is to be effective. However, this very limitation makes it easy to determine whether to attempt the shmat(), or just put up a default texture to indicate an inaccessible X server. The most typical would be: xserver://:1.0/shmem But to keep other netters from accidently hitting their own, use this style: xserver://yourhostname.and.domain:1.0/shmem ...which will cause the remote access to fail (incidentally being potentially loggable on your host) with the probable behavior of display a default texture on the intended surface (possibly with info on what contact was attempted). SPECIAL PROPERTIES ------------------ The XGLTEX server needs to put an Atom up containing the shared memory information to which texture clients can connect. This allow the clients to do everything they need to based solely on the standard DISPLAY notation, and also provides a convenient, access-controlled way to do a check for the shmem feature. Since the issue of shmem segments versus multiple screens in a server hasn't yet been worked out, the Atom should be extensible. So, an Atom name is needed, to store a list of integers, each of which is a shmid, ordered by screen index, say: SCREEN_SHMAT_IDS Making this a per-screen property (:0.0 vs :0.1) would simplify the process for most clients. Once a client has a shmid to use, presumably the actual format information will be obtainable from the buffer itself at some future time, perhaps as header information in the first block (512B) of the buffer, as seen in the SGI/IRIS RGB format. Note, however, that there are more valid texture formats than IRIS image formats, so the use of the latter is unlikely. Regardless, the SCREEN_SHMAT_IDS should probably include format information along with the shmids. GLUT ---- Oh yes. GLUT is evil. My use of it in some programs has turned out to be a mistake. You should create some alternative that allows callbacks to have arbitrary additional data to be attached to them for anything more involved.