There are two separate issues here: - glpaint vs glpaintx (2D) - OpenGL 2D looks reasonable and makes sense.
In OpenGL, for simple first implementation, espetially, to bring Java on the same page, it now uses OpenGL to draw to a bitmap. It was shown with my earlier sample code, which restores the old way as it was for windows, that, depending on complexity and harware, there is some 30%-200% gain in performance when drawing directly to screen without bitmap. However, currently the biggest bottleneck is the cd call. So that would be optimized first, then OpenGL should be turned back to drawing directly to screen, for windows. Even for Java it could be possible to investigate hardware support (there are solutions, like JOGL), but even more J-like -- just obtain a DC from Java, then the calls to OpenGL API will be done from J. BTW, obtaining a bitmap even while drawing to hardware is possible, as it was done in j504. --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
