--- Eric Iverson <[EMAIL PROTECTED]> wrote:
> You are correct re the overhead of pixels__ogl vs glaSwapBuffers. This
> overhead was always in the unix versions, but is new in windows. It should
> not take much additional mechanism to regain this effiicency. But for now I
> think it best to focus on the overall functionality rather than performance
For functionality, I think the paint API could be changed.
(Based on 'cube' demo)
Now it is required to have the boiler plate:
f_g_paint=: verb define
alloc__ogl wh NB. 1
...
glFlush'' NB. 2
glpixels 0 0,wh,pixels__ogl'' NB. 3
)
1. 2 and 3 are low-level implementation specific,
and could be put inside e.g. end__ogl
(Note: SwapBuffers seems to take care of glFlush)
2. Since we are already in OpenGL, by using
ogl=: 'g'conew'jzopengl'
we should probably hide the boiler plate (1-3)
alltogether, by providing automated paint handler
from the jzopengl and requiring a different callback
for actual user geometry, like 'draw'. E.g.
f_g_draw=: verb define
glViewport 0 0,wh
glMatrixMode GL_PROJECTION
glLoadIdentity''
gluPerspective 30, (%/wh),1 10
glClearColor 1 1 1 0
glClear GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT
glEnable GL_DEPTH_TEST
glMatrixMode GL_MODELVIEW
glLoadIdentity''
glTranslate 0 0 _8 NB. actual user geometry
glRotate R ,. 3 3 $ 1 0 0 0
drawbox ''
)
3. Most of the code above is some kind of OpenGL set up,
which for many cases is the same, esp. these 3 lines
glViewport 0 0,wh
glMatrixMode GL_PROJECTION
glLoadIdentity''
or identifiable with particular behaviors, like "Perspective" or
"Ortho", etc, with parameters. Since we already cover the boiler
plate, so it could also include the setup code like above.
The behavior scenario with parameters can
be set declaratively in the user class ctor calling
the jzopengl object. E.g.
ogl=: 'g'conew'jzopengl' NB. eliminate passing wh later
perspective__ogl 30, 1 10 NB. or ortho__ogl
clear__ogl 1 1 1 0 NB. or cleardepth__ogl
If such setup verbs are not called or called later with '',
then the boiler plait is not called and left to the user
for finer control.
This section is similar to facilities provided by gs... verbs,
but for the jzopengl API.
4. There is acceptance barrier for the gs... verbs (older std...).
The paint metaphor in 'jzopengl' is clear: you do all over every time.
But the gs... is kind of vague: you are not sure how much of it
is necessary to be called, what's doing what, etc. That is until you
study every of those verbs. But that's the mount of effort you
wrote your own init/fini functions to put common procedures.
The "simpler opengl" examples are great because they are stand alone.
Just copy all to an empty script and you are good to go.
The gs... are good for demo for compactness, but they are
not complete by themselves. So maybe the script in the demo
should include commented code before and after, so that
pasted into an empty script and uncommentin will produce
a stand-alone program. But that will clutter the definition.
Maybe such template already exists somewhere, but it's not
immediately locatable. If yes, it should be put in a more
prominent place. E.g. from or next to "View Definition", there
is "View Program" with full source, which will of course just
use the template and the definition to glue together.
5. As is was said may times, the most used and useful utilities
in J system are plot and viewmat (soon will be grid).
The reason is that they produce 95% of the useful results
in one line of code interactively.
It would be good to think of something to do something similar
with OpenGL. I don't know what it could be, but it would be very cool.
Just a thought ...
__________________________________________________
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
