Do you have an ATI card? The ATI proprietary driver has pbuffers implemented. pbuffers would let you avoid a lot of the swapping. If you run out of room for pbuffers you could go back to swapping.
I do have an ATI card, I'm developing on a mobility 9200 w/64MB ( also testing on nVidia Quadro).
That's an interesting question. pbuffers weren't implemented for the nvidia card when I started last June, so I didn't consider them. Do you know how they're implemented? The question is what is faster, changing drawables for the pbuffer context or one call to glCopyTexSubImage, drawing one solid fill "clearing" rect (less costly than glClear()), and one textured polygon. FYI, you have to use the closed source drivers to get a high-performance glCopyTexSubImage. I've been running my implementation at 1920x1200 and it's quite fast.
Would it be better to use xfs to cache the fonts?
Not sure about that one. I'm going for a stand-alone system that can run on top of X (or any system with OpenGL conforming to POSIX standards for the IPC). The only thing I use X for is the toplevel window and device input. The application model for my system is similar to X, albeit simpler.
I'm glad to see people are interested. That "replacement for X" I always hear about on /. could be just around the corner. I'll have to get my code up on sourceforge.
Cheers, Mike
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
