Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (762)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (847)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Future of OGL bindings  (Read 4426 times)
0 Members and 1 Guest are viewing this topic.
Offline Don Kiddick

Junior Devvie





« Posted 2006-04-26 05:05:33 »

Do you think the performance of J2D with the pipeline enabled will ever be comparable (say within 10%) with that of an OGL binding?
Just wondered,
D.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #1 - Posted 2006-04-26 15:10:21 »

Good question.

Offline campbell

Junior Devvie




Java games rock!


« Reply #2 - Posted 2006-04-26 16:28:18 »

Do you think the performance of J2D with the pipeline enabled will ever be comparable (say within 10%) with that of an OGL binding?
Just wondered,
D.

I'd say it's already there in Mustang, but you know I'm a bit biased in this case.  For a game that renders a couple thousand sprites onto the backbuffer each frame, there should be no discernable performance difference between Java 2D's OGL pipeline and an OGL binding (LWJGL, JOGL).  If your OGL app uses immediate mode rendering, then our OGL pipeline may actually be a slight win since we batch up our primitives to avoid unnecessary state changes and JNI overhead.

Anyway, why not write a simple app using both approaches and see what you get?  That way at least we'll have some hard numbers to chew on.

Thanks,
Chris
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #3 - Posted 2006-04-26 16:36:47 »

Quote
If your OGL app uses immediate mode rendering, then our OGL pipeline may actually be a slight win since we batch up our primitives to avoid unnecessary state changes and JNI overhead.
Immediate mode is hardly performant tho is it? Any decent application would either use display lists of VBO's; how does j2D compare with those?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #4 - Posted 2006-04-26 16:37:49 »

What's considerable is that with the OGL pipeline you get accelerated translucent images in Java 5. In Java 6 this acceleration is offered in the new D3D pipeline. Be aware that if you deploy a game via webstart than you can't enable the OGL pipeline since setting the system flag would be ignored by webstart for security reasons. But you're not limited to webstart as deployment options.

Offline campbell

Junior Devvie




Java games rock!


« Reply #5 - Posted 2006-04-26 18:37:16 »

Be aware that if you deploy a game via webstart than you can't enable the OGL pipeline since setting the system flag would be ignored by webstart for security reasons.

This was fixed in Mustang (JDK 6).  You can now pass sun.java2d.opengl=true to a webstarted application.

Chris
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #6 - Posted 2006-04-26 18:39:49 »

Cool but this forces users to very likely download ans install Java 6, which bad because of the size of the JRE.

Any chance of backporting this flag to webstart Java 5?

Offline campbell

Junior Devvie




Java games rock!


« Reply #7 - Posted 2006-04-26 18:42:52 »

Quote
If your OGL app uses immediate mode rendering, then our OGL pipeline may actually be a slight win since we batch up our primitives to avoid unnecessary state changes and JNI overhead.
Immediate mode is hardly performant tho is it? Any decent application would either use display lists of VBO's; how does j2D compare with those?

DP

That's the point I was getting at, but I didn't state it explicitly; I was comparing apples and apples, Java2D's OGL pipeline to an app that uses OGL bindings in immediate mode.  Immediate mode isn't all bad, but of course if you use vertex arrays/buffers you have the potential to be faster than simply using immediate mode.  But again, someone should hack up a testcase that compares all of these approaches (Java2D, LWJGL/JOGL w/ and w/o immediate mode) and then we will have some data.

Thanks,
Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #8 - Posted 2006-04-26 18:47:14 »

Cool but this forces users to very likely download ans install Java 6, which bad because of the size of the JRE.

Any chance of backporting this flag to webstart Java 5?

There were enough issues with the OGL pipeline in JDK 5 (e.g. performance, robustness) that there probably wouldn't be much benefit in having it backported.  Still, if you want your voice heard you could post a comment on this bug report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250769

Chris
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #9 - Posted 2006-04-26 19:10:36 »

Well, I agree. I doubt that it's worth voting for it.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Zer Gut Shnitzel

Senior Newbie





« Reply #10 - Posted 2006-04-27 05:25:24 »

Hi there,

Recently I did a speed comparisons of some very basic 2D drawing methods, basically I was just drawing lines on a canvas from a rendering loop and watching my frame rates. I have been comparing JRE1.5 plain Java2D , Mustang with OGL pipeline and JRE1.5+JOGL 1.1 implementations here are some of the results, sorry for being vague here as I don't have time to dig up and rerun my benchmarks and post exact numbers and code.

JRE1.5  Java2D with default direct draw pipeline was ranging from 17 fps for 20000 lines up to 350 fps for 1000 lines JRE 1.5 with open gl pipeline was actually running slower than this it would give me 2 fps for 20000 lines

Mustang Java 2D (one of release candidates I grabbed from sun's page) ranged from 15 fps with 200000 lines to 1500 fps with 1000

Java2d implementation used AWT canvas & buffer strategy as a rendering loop (I think this is what I have found around here as the most recomended rendering mechanism)

JRE1.5 JOGL 1.1 was drawing 2000000 lines with around 15 fps

I noticed that with pure JOGL I was able to increase number of lines while frame rate would only slightly go down while with Java2d the increas in number of lines would decrease my frame rate almost linearly.

Please note that I did these kinds of tests just for the purpose of picking the right API for very specific purpose, my rendering engine only ever paints 2d lines. So it would be interesting to see how the API's would compare when they are doing doing bitmaped graphics as well.  With JOGL it is possible to avoid the JNI overhead by using Buffers.
Offline CommanderKeith
« Reply #11 - Posted 2006-04-27 11:21:22 »


More detail would be great.  Antialiased lines or jaggies & how long are they?  How big is the screen (800x600?)?

I'm interested to know if I should invest in learning JOGL or just use the OGL pipeline like I am now. 

My biggest gripe about J2D is that the y coordinate axis is backwards and flipping it ( AffineTransform.scale(1, -1) ) causes loss of graphics hardware acceleration.

On the other hand, the OGL pipeline is awesome because you can switch between OGL and the default renderer without any work.  JOGL would make me stuck, and apparently so many cheap graphics cards are faulty/have faulty drivers when it comes to OGL.

Keith

Offline Don Kiddick

Junior Devvie





« Reply #12 - Posted 2006-04-27 22:20:26 »

Am I right in thinking there is only an OGL pipeline in JRE 1.5+ on Windows?

Anyway it sounds like the future for OGL accelerated J2D is rosy and as my game hardly 'pushes the envelope' I think I'll stick with it for the moment!

D.
Offline Linuxhippy

Senior Devvie


Medals: 1


Java games rock!


« Reply #13 - Posted 2006-04-28 06:11:13 »

Am I right in thinking there is only an OGL pipeline in JRE 1.5+ on Windows?

No, the OpenGL pipeline is also available at least for Solaris and Linux, don't know about others.
However since IBM's jre also supports this flag I guess its also supported on AIX if appropriate hardware would be / is available.

However keep in mind that it was ugly in 1.5 (very slow and unstable) and that still many drivers have problems with it.
I would at least offer a workarround for using the old pipeline if the OpenGL one does not work as expected.

lg Clemens
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (368 views)
2018-06-10 19:43:48

EgonOlsen (374 views)
2018-06-10 19:43:44

EgonOlsen (305 views)
2018-06-10 19:43:20

DesertCoockie (549 views)
2018-05-13 18:23:11

nelsongames (874 views)
2018-04-24 18:15:36

nelsongames (857 views)
2018-04-24 18:14:32

ivj94 (1318 views)
2018-03-24 14:47:39

ivj94 (437 views)
2018-03-24 14:46:31

ivj94 (1100 views)
2018-03-24 14:43:53

Solater (449 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!