Oleg Kobchenko wrote: > OpenGL looks better in Java. However, performance > is both in Windows and Java is like it used to be > in Java.
First off, I have to say that personally I love the way this is going. Despite the slowdown. I'm a big fan of "first make it right, then make it fast (otherwise you wind up with something that does the wrong thing, really fast)". But even I have to recognize that an order of magnitude slowdown will bother some people. > More details below. But the bottom line is that > still it would be hard to make cd and DC/RC perform > the way it used to under Windows. OpenGL was a good > showcase how fast J can perform in critical conditions. I don't know that I should agree with the "it would be hard". But I can agree with your other sentence about OpenGL being a good showcase for J. > The call for generalized OpenGL was to be extensible > with more OpenGL functions. I think I requested the ability to use it to drive glpixels in the isigraph control. But given the huge performance penalty of that route, I guess I have to agree that drawing directly from opengl (with the isigraph's rendering simply turned off) is also important. Another useful rendering path is going to be "render within opengl and then use glCopyTexImage2D (&family) to move pixels around within the opengl environment". > One possibility would be to leave the implementation > at it was for most of the functions, especially the > drawing primitives, which are called frequently. And > then allow to call other API functions, such as > configuration. That would work. Personally, I'd rather see a 15!: api that did not require scalar boxing, with special code to support argument patterns associated with the drawing primitives. For example, imagine that 15!:10 was an adjective where x 15!:10 y worked like x 15!:0 <>y and where glVertex4d on windows looks like 'opengl32.dll glVertex4d n d d d d' 15!:10 and where, inside J, this corresponds to a simple wrapper that has obtained the proper library entry point and which is specifically implemented for that argument pattern. It would, as directly as possible, pull scalars out of y and call the named entry point. > > I'm not sure if this is worth it, but would consider > > it if presented with arguments. > > In "cube" OpenGL Lab Demo with window size > about 1000x1000, I compaired > > smoutput 6!:2 'drawbox $0' > > It's ~x3 slower in new Win OpenGL. Note that the cube demo doesn't use much geometry. Therefore, it's not a good example to use to justify speeding up the rendering of geometry. Also note that the cases where rendering geometry quickly will be critical are cases where the display is highly dynamic. For example, a physics simulation would probably be more dynamic than any of the current demos, and fluid dynamics simulations might involve considerably more variable geometry than simulations of a spring. (Or maybe not?) Studying the code, I think most of the time penalty you see for the cube demo is at the last line of the paint event handler. The upside here is that once you have a static image, rendering becomes much more efficient (the paint event handler does not fire at all for a screen refresh). The downside you've already identified. I'm also under the impression that most of the hard implementation work has been done. Maybe I'm overconfident, after seeing so many order-of-magnitude improvements in J performance, but I think that the current design is not the problem. I think the problems can be isolated down to a few specific areas which can be made just as fast as J5's implementation. Or perhaps faster. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
