Eric Iverson wrote: > 2. glpaintx - you have mentioned this before and only now does a little > light go off. glpaintx hasn't changed. It marks the control invalid and > that will eventually get a paint message to the host. What has changed
> it that now the way isigraph works now with a memory buffer it simply > says 'got a buffer of the right size and blts it over'. This isn't > right, but I'm going to have to think it through a bit. I think you also have a potential performance issue here. Correct me if I'm wrong, but if you're using OpenGL's special hardware support for flipping buffers, the pixels are not buffered. OpenGL expects rendering code to be run to create a fresh set of pixels in another buffer, and takes advantage of the fact that the video card has direct control over what gets rendered where on the screen. For example, if I do a physics simulation, perhaps of wave action on a liquid surface, my performance bottleneck is probably going to be pumping new images to the screen. Retaining pixels reflecting a static image won't help. Of course, if I'm rendering a checker game, or a solitaire game or something like that, I'll probably be able to get some good use out of static images. But those kinds of things are more for learning how to deal with opengl. It's also possible to use opengl as a specialized computational facility. (http://www.gpgpu.org/) and pulling data back from the video card becomes important if you're doing that -- but these cases aren't so important that you should abandon the use of hardware support for rendering. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
