useful Java2D bridge

JOGL 1.1.1 had a very simplistic method to draw Swing into OpenGL - just render Swing into an image and then into OpenGL.  But I needed a way to accelerate rendering Swing into OpenGL and I wrote a bridge to do that.  I actually implements the Graphics2D class and makes glRectf, glColor, etc. calls to support the Graphics2D object.

Has this been done already or improved in the 2.0 release?  Are there plans to do it?

This is my (incomplete) project https://github.com/brandonborkholder/glg2d

On Tuesday, October 04, 2011 02:56:09 AM brandon [via jogamp] wrote:
>
> JOGL 1.1.1 had a very simplistic method to draw Swing into OpenGL - just
> render Swing into an image and then into OpenGL.  But I needed a way to
> accelerate rendering Swing into OpenGL and I wrote a bridge to do that.  I
> actually implements the Graphics2D class and makes glRectf, glColor, etc.
> calls to support the Graphics2D object.
>
> Has this been done already or improved in the 2.0 release?  Are there plans
> to do it?

Not by myself, since I consider Java2D dead. But thats only my personal opinion.
I remember that I did something like this in the very past for GL4Java
some 13 years ago, but never really completed it :)

Of course, using JOGL to implement the Graphics2D core to allow AWT/Swing
being rendered w/ GL seems to be very nice - KUDOS.
Especially if this could be done in GL2ES2 .. w/ shaders.

If I understand you right, you have implemented such a thing w/ glg2d ?
Do you like to add this to JOGL under our license / copyright ?
Of course you and others are more than welcome to do so,
especially if you like to maintain it as well. IE bugfixes, unit tests etc.

Please let me know, then we can discuss further steps.
Again: You are more than welcome.

Cheers, Sven

>
> This is my (incomplete) project https://github.com/brandonborkholder/glg2d

Hi

Thank you so much, it would be a nice temporary solution to port APIs relying on Java2D to JOGL. There were some old projects doing it (Agile2D, GTGE, etc...) but they are no more maintained. I'm going to look at your source code. Thank you for sharing :)

I agree with Sven but it would be fine if your source code could work with plain OpenGL 1.2 too without shaders.

Edit.: Nice source code :)

Edit.2: As there are a lot of dependencies with AWT, it won't work on mobile phones but it could work with NEWT.

Edit.3: Storing the GL instance is not a good idea in my humble opinion. It can be invalidated and using an invalid one is not good..... Maybe you could use the same array in static methods to avoid creating a lot of arrays. GLGraphics2D should be called on the same thread as it depends on OpenGL and making a single OpenGL context current on different threads might not work on some platforms.

Sure, I'd be happy to merge my project with JOGL.  I have no problem changing the license.

I did consider starting to use shaders, but just haven't gotten that far.  And as for Java ME, I haven't even thought about that.  My goal has been pretty limited so far - just make the usual cases faster.

gauessej, I make the GL instance a member in a lot of places to make it easy. But I do update the field on each call to display().  (See https://github.com/brandonborkholder/glg2d/blob/master/src/joglg2d/GLGraphics2D.java#L99)

I guess the next step for me is to port over to JOGL 2.0, then a merge might be possible.

Lol don't break my pseudo (gouessej != gauessej).

If you plan to use shaders, please could you support both rendering with them and rendering without them?

If you need some help for the port, let me know.

Ok your solution is smarter than I thought, you're right.

I find your solution promising, really. It would be fine to try to use it with JFreeChart.

gouessej wrote

Lol don't break my pseudo (gouessej != gauessej).

My bad :)  forgot my contacts at home this morning

gouessej wrote

If you plan to use shaders, please could you support both rendering with them and rendering without them?

Agreed, it should degrade gracefully depending on what's available.  There really isn't anything that shaders will buy, I'd basically end up reimplementing the fixed-function pipeline.  The big exception is geometry shaders.  That would significantly speed up line drawing.

I really wanted to implement java.awt.Composite using shaders, until I found out a shader can't get the current color fragment value...

On Tuesday, October 04, 2011 09:32:57 PM Brandon Borkholder [via jogamp] wrote:
>
>
> Agreed, it should degrade gracefully depending on what's available.  There
> really isn't anything that shaders will buy,

But that fixed function pipeline (FFP) might not be even available -> mobile/ES2.
Pls also mind that FFP is emulated on today's GPUs..
  http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html

> I'd basically end up
> reimplementing the fixed-function pipeline.  The big exception is geometry
> shaders.  That would significantly speed up line drawing.

Also writing shader(s) which do the job matching the exact needs incl.
data management (VBO caching .. etc) usually is more efficient.
Again, driver for today's hardware usually generates shaders on the fly
to emulate the FFP.
However, we may can do that later, of course.

Awesome that you are willing to bring this very useful module into JOGL.

>
> I really wanted to implement java.awt.Composite using shaders, until I found
> out a shader can't get the current color fragment value...

A compositor usually blends previous generated FBOs,
which you can ofc use as textures in shaders.
Thats how the new KDE w/ ES2 impl. does it.

~Sven

Hi,
It seems to be a really interesting work. In what is this different from using -Dsun.java2d.opengl=true?
Cheers,
Martin

It is different because it works. On some Windows machine, I don't dare setting this flag to true because the OpenGL pipeline is not in a very good health in Java under Windows (whereas it works fine under GNU Linux).

This flag only enables to accelerate some operations including transformations, it has nothing to do with a fully hardware accelerated Java2D implementation.

gouessej wrote

It is different because it works. On some Windows machine, I don't dare setting this flag to true because the OpenGL pipeline is not in a very good health in Java under Windows (whereas it works fine under GNU Linux).

That's completely true. On my windows 7 machine, it does not work (all the interface remains white). I thought I was in a specific case with weird graphic device configuration.

Does it mean using JOGLG2D will be using GL efficiently for java 2d transforms? Such as:
Graphics2D.getTransform()
AffineTransform.getRotateInstance(angle);
AffineTransform.getTranslateInstance(position.getX(), position.getY());
AffineTransform.concatenate(...)
...

Regards,
Martin

Martin wrote

gouessej wrote

It is different because it works. On some Windows machine, I don't dare setting this flag to true because the OpenGL pipeline is not in a very good health in Java under Windows (whereas it works fine under GNU Linux).

That's completely true. On my windows 7 machine, it does not work (all the interface remains white). I thought I was in a specific case with weird graphic device configuration.

Does it mean using JOGLG2D will be using GL efficiently for java 2d transforms? Such as:
Graphics2D.getTransform()
AffineTransform.getRotateInstance(angle);
AffineTransform.getTranslateInstance(position.getX(), position.getY());
AffineTransform.concatenate(...)
...

Regards,
Martin

Yes, it does use OpenGL projection matrix for all transforms, but only if
you use Graphics2D directly (e.g. Graphics2D.setTransform(AffineTransform),
Graphics2D.translate(int, int), etc.)  Everything that should be
transformed is transformed on the GPU.

On 02/15/2012 01:14 PM, Brandon Borkholder [via jogamp] wrote:
>
>
> Yes, it does use OpenGL projection matrix for all transforms, but only if
> you use Graphics2D directly (e.g. Graphics2D.setTransform(AffineTransform),
> Graphics2D.translate(int, int), etc.)  Everything that should be
> transformed is transformed on the GPU.
>

Nice to read about your project again.

- Have you ported it to JOGL2 already ?

- Is it ready to be included in our builds as a module ?

Cheers, Sven

I just recently ported it to JOGL 2.0-rc5.  It's ~90% feature-complete and I think it's ready to be included with jogamp builds.  My next big task will be to implement most of the drawing using shaders rather than the fixed function pipeline.  But that can happen later.

Should we start a new thread to talk about the module process?

On 02/15/2012 06:39 PM, Brandon Borkholder [via jogamp] wrote:
>
>
> I just recently ported it to JOGL 2.0-rc5.  It's ~90% feature-complete and
> I think it's ready to be included with jogamp builds.  My next big task
> will be to implement most of the drawing using shaders rather than the
> fixed function pipeline.  But that can happen later.
>
> Should we start a new thread to talk about the module process?

that would be greatly appreciated - yes!
maybe 'glg2d-module'

sounds great sir!

~Sven

Sounds good!
Actually I tested it a few month ago on a demanding java2d app and it did not notice improvements. Maybe I did not used the component as required.
I remember wondering if calling setContentPane(new G2DGLCanvas(myJPanel)); will propagate the GL Graphics2D to all sub component added by myJPanel, so that any children of myJPanel would retrieve your GLGraphics2D when calling getGraphics() on it. On top of an heavy java2D renderer, I use JDesktopPane with JInternalFrames, and I wrapped this JDesktopPane with G2DGLCanvas.
The way you inject the feature is definitly excellent, and the comparison test suite coming with is equally stunning. Having a rendering time/fps indication in the unit test comparator would be great.
Eager to try the new version!
Cheers,

I would still prefer to keep some support of the fixed pipeline anyhow because I still need to use some APIs relying on JOGL on machines only supporting OpenGL 1.3...

Martin, it would be useful to have you app as a testcase.  Java2D painting is amazingly convoluted and I've found it really hard to make sure swing components are being painted in glg2d and not in Java2D.

There's an effort to modularize the painting so it can be delegated properly. Marrio Torre (I believe with Roman Kennke) developed Caciocavallo http://ladybug-studio.com/caciocavallo/ and the idea is to make it easy to have one place to change the painting subsystem. I've been wanting to look at their code, maybe even leverage it.

But the short answer is that you might be right. So far, I've found no speedup when using swing repainting (my UIDemo class) and multiple levels of JComponents. I think the problem is a combination of too much logic in deciding what to paint and being expensive to fire an OpenGL display call when a little button just wants to repaint the border.

But if you ignore that and look at my GraphTest class (a single JPanel painting a lot of objects) glg2d wins easily. It's much more responsive when making a lot of Graphics2D calls on the same paint call.

On 02/17/2012 12:57 PM, Brandon Borkholder [via jogamp] wrote: Very good you mentioned the AWT/Java2D replacement.
This would even allow us to plugin something 'swing' into
non AWT platforms. And I believe Marrio's and Roman's implementation
is far better modularized than the historically grown AWT/Java2D.

~Sven

On 02/17/2012 10:56 AM, gouessej [via jogamp] wrote:
>
>
> I would still prefer to keep some support of the fixed pipeline anyhow
> because I still need to use some APIs relying on JOGL on machines only
> supporting OpenGL 1.3...
>

Which would be the ancient backend .. still being maintained, sure.

TBH .. todays machines all sort of offer some sort of GL ES2
and even desktop implementations require it to allow hw accelerated rendering.
IMHO .. it's not even the future, but a technical fact today.

Of course, it's not up to me to discourage maintenance of an OpenGL 1.3
backend - I just wanted to share my opinion of my POV.

~Sven

> > There's an effort to modularize the painting so it can be delegated
> > properly. Marrio Torre (I believe with Roman Kennke) developed Caciocavallo
> > http://ladybug-studio.com/caciocavallo/ and the idea is to make it easy to
> > have one place to change the painting subsystem. I've been wanting to look
> > at their code, maybe even leverage it.
> Very good you mentioned the AWT/Java2D replacement.
> This would even allow us to plugin something 'swing' into
> non AWT platforms. And I believe Marrio's and Roman's implementation
> is far better modularized than the historically grown AWT/Java2D.

Not sure what you mean by "something swing" in non AWT platforms.  You
mean drawing Swing on something like Android?  It doesn't have AWT,
but you could run Java libraries and make OpenGL calls.  Not sure
there's a use case for that, but it seems like it would be possible.