Re: [Fenfire-dev] Yet another libvob API: LWJGL

[Matti Katila]

On Fri, 13 Jan 2006, Tuukka Hastrup wrote:
> > What kind of benchmark or comparing method you suggest? If there's a
> > missing binding the developers were interested in to add it.
> > That was the impression they give me at #LWJGL.
>
> I don't know exactly, but I suppose something that's similar to how
> Fenfire would stress the interface.

Last evening I asked on #LWJGL about the jni overhead and the answer was
beneath the lines that you need to test it. So I modified
http://cvs.sourceforge.net/viewcvs.py/java-game-lib/LWJGL/src/java/org/lwjgl/test/opengl/Gears.java?rev=1.5&view=log
to not use call lists. Here is the summary from 1 to 50 gears:

                                        = X fps, triangles

4021 frames with 1 gears in 5.0 seconds = 804.2 trids: 164
2004 frames with 5 gears in 5.0 seconds = 400.8 trids: 820
1198 frames with 10 gears in 5.0 seconds = 239.6 trids: 1640
840 frames with 15 gears in 4.998 seconds = 168.06721 trids: 2460
649 frames with 20 gears in 5.0 seconds = 129.8 trids: 3280
536 frames with 25 gears in 4.999 seconds = 107.22144 trids: 4100
443 frames with 30 gears in 4.997 seconds = 88.65319 trids: 4920
393 frames with 35 gears in 4.995 seconds = 78.67868 trids: 5740
345 frames with 40 gears in 4.72 seconds = 73.09322 trids: 6560
299 frames with 45 gears in 4.998 seconds = 59.82393 trids: 7380
281 frames with 50 gears in 4.995 seconds = 56.256256 trids: 8200

I am not 100% sure of the trid count, though.


Ok what we can do with this information? Let's say that we use lobs to
fill the scene with text. If we can put 600 words per (academic text) page
(http://www.writersservices.com/edres/p_word_count.htm)
and one word has aproximately length of five. Every character takes 2
trids to render into rectangular texture. 8200/2 / (600*5) ~= 1 page with
more than 50 fps in my machine. Well it's not good but not the worst
case either. If we put just a few images instead we get much better
results of course.


> Perhaps a "Fenfire demo" that builds a
> scene like we would in reality and then animates it to see how
> much resources it takes.

Well, go ahead :-)


> Right, was one of the requirements to have as few JNI calls per frame as
> possible?

Then we come back to the start point, that's the system we have now.
There still are the same issues.


> And was this a reason why none of the wrappers would do, as
> they concentrate on games?

Well, we haven't ever been there. When architecture is constructed it has
needs to fulfill, i.e., requirements. I think speed was one of those
requirements and Tuomas though that one jni call per frame would do
that. We don't know whether a more than one jni call per
frame is acceptable. This mode, where you have a freedom to draw anything
on frame, is called as intermediate mode in game scenes.


> Perhaps that part of Fenfire could find its way
> to one of the other wrappers.

Not really. Native libvob is not a wrapper anymore. It does 3/4 of the
work of libvob and has basically the libvob architecture and requirements.
That's not something we share with other projects. pad++ comes to my mind
but as I recall it doesn't have OpenGL at all and the implementation
language is not Java either.


   -Matti