Hi, I've just pushed a variation on a theme a couple of people have explored in the past, ie. an interface to gallium without an intervening state-tracker.
The purpose of this is for writing minimal test programs to exercise new gallium drivers in isolation from the rest of the codebase. In fact it doesn't really make sense to say "without a state tracker", unless you don't mind creating test programs which are specific to the windowing system you're currently working with. Some similar work has avoided window-system issues altogether by dumping bitmaps to files, or using eg. python to abstract over window systems. This approach is a little different - I've defined a super-minimal api for creating/destroying windows, currently calling this "graw", and we have a tiny little co-state-tracker that each implementation provides. This is similar to the glut approach of abstracting over window systems, though much less complete. It currently consists of three calls: struct pipe_screen *graw_init( void ); void *graw_create_window(...); void graw_destroy_window( void *handle ); which are sufficient to build simple demos on top of. A future enhancement would be to add a glut-style input handling facility. Right now there's a single demo, "clear.c" which displays an ugly purple box. Builds so far only with scons, using winsys=graw-xlib. Keith ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
