OpenGL looks better in Java. However, performance
is both in Windows and Java is like it used to be
in Java.
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.
The call for generalized OpenGL was to be extensible
with more OpenGL functions. 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.
> 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.
drawbox consists only of pure J and OpenGL calls
(now bitmat swapping etc.,) which are different so
glVertex_jgl3_ NB. j5
11!:3149
6!:2 'glVertex_jgl3_"1 i.100 4'
0.000495594
glVertex_jgl3_ NB. j6
[EMAIL PROTECTED](4 = {:@$)
glVertex3d_jgl3_
'opengl32.dll glVertex3d n d d d' 15!:0"1 <&>
6!:2 'glVertex_jgl3_"1 i.100 4'
0.00466568
This is ~x10 in pure calls. This is the most
compelling argument that cd cannot match fc call
in performance. And boxing may not have much to do
with it:
6!:2 'glVertex_jgl3_"1 i.100 4' NB. j6
0.00428658
6!:2 'glMatrixMode_jgl3_"0 i.100'
0.00116244
The performance issue may also lie in the way
OpenGL is applied to the window.
The previous implementation of Windows OpenGL
worked with the overlay delegating rendering
and refreshing to the underlying systems, possibly
relying on the GPU support. Whereas it looks like
this implementation redirects OpenGL to a bitmap,
fetches its pixels and then copies them to the
real DC. So there is no way to gain the benefits
of the GPU support.
However, it is possible to draw directly to the
window DC from J code with cd. This gives on 'cube'
demo full screen visually about x2-3 speed gain.
Surely, it's an implementation improvement for Java,
but maybe it would be possible to get Java window peer DC
and also let OpenGL draw directly without bitmap.
NB. ===================================[jzopengl_win32.ijs]====
alloc=: 3 : 0
free''
hdc=: 0{::GetDC hwnd NB. hwnd: y{2 or from 'create' ctor
pfd=: mpfd''
if. pixfmt=0 do.
pixfmt_jzopengl_=: >{.ChoosePixelFormat hdc;pfd
end.
r=. a.i.>{.SetPixelFormat hdc;pixfmt;pfd
'pixelformat failed' oglassert r~:0
hglrc=: >{.wglCreateContext hdc
if. (0=hglrc)*.0=ONETIME do.
ONETIME_jzopengl_=: 1
alloc y
end.
'context failed' oglassert hglrc
r=. >{.wglMakeCurrent hdc;hglrc
'makecurrent failed' oglassert r~:0
wh=: y
i.0 0
)
free=: 3 : 0
wh=: 0 0
pad=: 0
if. hglrc do.
wglMakeCurrent 0;0
wglDeleteContext hglrc
hglrc=: 0
end.
if. hdc do.
SwapBuffers hdc
ValidateRect hwnd;0
ReleaseDC hwnd;hdc
hdc=: 0
end.
i.0 0
)
PFD_DOUBLEBUFFER =: 16b00000001
PFD_DRAW_TO_WINDOW =: 16b00000004
PFD_DRAW_TO_BITMAP =: 16b00000008
PFD_SUPPORT_OPENGL =: 16b00000020
mpfd=: 3 : 0
a=. 40{.40 00 01 00,(PFD_DOUBLEBUFFER+PFD_DRAW_TO_WINDOW+PFD_SUPPORT_OPENGL),00
00 00 00 32
a=. 32 (23})a NB. cDepthBits
_2(3!:4)40{.a{a.
)
SwapBuffers=: 'opengl32.dll wglSwapBuffers i i'&(15!:0)
GetDC=: 'user32 GetDC i i'&(15!:0)
ReleaseDC=: 'user32 ReleaseDC i i i'&(15!:0)
ValidateRect=: 'user32 ValidateRect i i i'&(15!:0)
--- Eric Iverson <[EMAIL PROTECTED]> wrote:
> You raise an interesting point I have been thinking about. Currently 15!:0
> targets arguments of various types and always requires boxing each. This has
> never been an issue. However the opengl API has a large class of calls,where
> performance may be an issue, that have scalar args of the same type. It
> would be fairly easy to introduce a new 15!:x that took a list of scalars.
> I'm not sure if this is worth it, but would consider it if presented with
> arguments.
>
> ----- Original Message -----
> From: "Miller, Raul D" <[EMAIL PROTECTED]>
> To: "Beta forum" <[email protected]>
> Sent: Tuesday, April 04, 2006 6:48 PM
> Subject: RE: [Jbeta] 601 j beta for windows now available.
>
>
> A few more notes, working through the opengl lab:
>
> > (18 of 42) Isigraph Control (ctd)
> > Calls with all scalar args are defined to box each scalar (as
> > required by cd) and to be rank 1. This allows calls with a
> > simple scalar list and allows application to tables.
>
> Wouldn't unboxed right arguments with 15!:0 be radically more
> efficient for these cases? (Not that efficiency should be
> a primary concern, but in this case it also seems like it
> should be simpler.)
>
> > (19 of 42) Isigraph Control (ctd)
> ...
> > modifiers) is often added for the common case. For
> > glVertex... the added definition is: glVertex=: glVertex4d
>
> That's not completely accurate. (Not that I'm complaining,
> I'm talking about minor rough edges here, and releasing even
> a small piece of software can involve a lot of work and time.)
>
> glVertex__ogl
> [EMAIL PROTECTED](4 = {:@$)
>
> I'd also be inclined to use
> [:`[:[EMAIL PROTECTED]({:@$)
>
> > (32 of 42) Cube (ctd)
>
> Here, I got an error:
>
> error in: jijs_jctrl_fkey
>
> domain error: gluDeleteQuadric
> gluDeleteQuadric obj
>
> Also, when I restarted the lab without creating a fresh J
> session, no opengl rendering window would appear (though
> the buffer manipulations without a window seemed to work
> just find).
>
> When I restarted the lab in a fresh J session, section 32
> seemed to work just fine, so I'm suspecting a race condition.
>
> FYI,
>
> --
> Raul
__________________________________________________
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
