JOGL too slow

Thread view:

Reza Roby - 07 May 2004 03:51 GMT

Arrrg... cross posted incorrectly the first time. Sorry :(
-------------------------------------------------------------

Hi guys,

I've written an application that makes many OpenGL calls for rendering a
scene. (The calls are glColor3f and glVertex3f, mostly.)

when my loops make about 1,400,000 additional calls to glColor3f, render
time goes from 50 Milliseconds to 300 Milliseconds!

Straight c (gcc/linux) can do 1,400,000 glColor3f's, 20 times as fast
(same hardware.)

This suggests the jogl->OpenGL bridge is very slow.

I could be wrong, but I think not.
------------------------------------------------

My question is not JOGL specific:

Can you briefly explain how the Java->native bridge is implemented?

How that explains the JOGL slowness?

And if it can be made faster?

I chose Java for it's seamless platform independence, and fairly decent
JIT, but Java->OpenGL speed is crucial.

I am presently looking into wxWindows and wxGLCanvas as a potential
alternative.

I really appreciate any help that makes my decision easier.

PS:

I won't shy away from reading the JOGL source code, if you tell me how
it works, and what to do.

Reply to this Message

Vincent Cantin - 24 Jun 2004 18:25 GMT

> I've written an application that makes many OpenGL calls for rendering a
> scene. (The calls are glColor3f and glVertex3f, mostly.)

Don't you know that there some others way to display polygons ?
You choosed the more slow one.

> How that explains the JOGL slowness?
> And if it can be made faster?

Use display lists, vertex buffer and vertex objects

Reply to this Message

java programmer - 15 Jul 2004 20:28 GMT

it depends on what you want to do.

in general and as mentioned by vincent below
it is a good idea to save some calls to jogl (over jni)
by apllying powerful calls that do a lot at once.

hope it helps.

me

> > I've written an application that makes many OpenGL calls for rendering a
> > scene. (The calls are glColor3f and glVertex3f, mostly.)
[quoted text clipped - 6 lines]
>
> Use display lists, vertex buffer and vertex objects

Reply to this Message

Stephen H. Westin - 15 Jul 2004 21:01 GMT

> it depends on what you want to do.
>
[quoted text clipped - 16 lines]
> >
> > Use display lists, vertex buffer and vertex objects

I'm a novice here, but is Vincent using a GLCanvas (which can be
hardware-accelerated), or a GLJPanel (which can't)? Seems to me that
might make a difference. And if the former, is everything working to
give him hardware acceleration? What's the hardware platform, anyway?

Signature

-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.

Reply to this Message

Vincent Cantin - 19 Jul 2004 17:09 GMT

> I'm a novice here, but is Vincent using a GLCanvas (which can be
> hardware-accelerated), or a GLJPanel (which can't)? Seems to me that
> might make a difference. And if the former, is everything working to
> give him hardware acceleration? What's the hardware platform, anyway?

I am using GLCanvas. It seems that this detail is not the focus of "Reza
Roby" anyway.
I still didn't tried GLJPanel, but I saw that it can be hardware accelerated
also if the hardware support the render-to-texture feature.

I am making professional 3D games, and I am using Java to build my tools. In
most of the cases, I don't need to make a lot of JOGL calls compared to the
huge amount of data I am using. All is used in vertex array, display, vertex
buffer, CG (for skeleton animation) , etc ... Java don't have to do a lot of
work anyway, so finally it cannot be slow.

Vincent

Reply to this Message

Brian Matzon - 19 Jul 2004 17:21 GMT

> I am making professional 3D games, and I am using Java to build my tools. In
> most of the cases, I don't need to make a lot of JOGL calls compared to the
> huge amount of data I am using. All is used in vertex array, display, vertex
> buffer, CG (for skeleton animation) , etc ... Java don't have to do a lot of
> work anyway, so finally it cannot be slow.

You could try using LWJGL (http://lwjgl.org), might be a JOGL issue.
I am bit curius, why are you only using Java as the tools, why not go
all the way? - It has worked fine for several developers using LWJGL.
Including the recent winner of the Java Technology Game Development
Contest (2004).

Might want to check out:
http://puppygames.net/ - Alien Flux (Commercial offering) & Super Elvis
(Winner of contest, soon to be released).

http://oddlabs.com/ - Tribal Trouble (fun looking realtime strategy game)

/matzon

Reply to this Message

Vincent Cantin - 03 Aug 2004 18:38 GMT

> > I am making professional 3D games, and I am using Java to build my tools. In
> > most of the cases, I don't need to make a lot of JOGL calls compared to the
[quoted text clipped - 6 lines]
> Including the recent winner of the Java Technology Game Development
> Contest (2004).

... mainly because my boss is laughing each time I am speaking about Java

:-(

Reply to this Message

JOGL too slow

Free Magazines