How slow/fast is GradientPaint?

Java 2D
#1

Hi there!

I plan to use GradientPaint a lot but I am a bit afraid about its performance - and since a switch to GradientPaint would involve a lot of code changes I ask here before I’ll try.

How well does GradientPaint perform, and how well does the OpenGL-Pipeline with GradientPaints?

Thanks in advance, lg Clemens

#2

It’s rather slow. (Dunno how the GL pipeline performs.)

But do you really need to do it in real time? Each frame? :slight_smile:

Try using opaque images as… uhm… “cache”. Create those tiles on startup and then just use drawImage.

#3

I seem to remember the ogl pipeline does accelerate gradient fills.

#4

GradientPaint is accelerated in hardware by the OpenGL-based pipeline using texture mapping tricks. It’s ridiculously fast… With the OGL-based pipeline, enabling a GradientPaint has almost no impact on performance (compared to using just a simple Color). Keep in mind though, in 5.0 GradientPaint can only be accelerated when antialiasing is off (I’d like to remove this restriction in a future release). For more info:
http://today.java.net/pub/a/today/2004/11/12/graphics2d.html

Chris

#5

Thank for your detailed replies - they helped me a lot in my design!

@Chris: Of course I read this document - Its a clear must for everybody interrested whats going on in Java2d.

However, a sad thing I saw when running the gradient-paint demo in Java2D-Demo is that without antialiasing performance is completly bad (90fps with and 0.5fps without antialiasing).
Seems like my graphic-board (GeForceGo-488 with latest linux-drivers) does not very well with Java2D - some operations are faster (image blitting) but most common operations like filling rects are slower :frowning:

Anyway thanks a lot for the information!!!

lg Clemens

#6

so basically drawing an 100x100 managed-image is faster than a 100x100 GradientPaint - right?

Thanks in advance, lg Clemens

#7

With the default pipeline, yes - a lot. With opengl the gradient might be even a tad faster, but it’s very very fast vs very fast (instead of very fast vs very slow).

#8

last question - I don’t want to nerve anymore…

For now I do cache 50 images with gradients (mostly very small) and I delete that one which was not used for the longest periode of time.
Every image I delete from cache I immedetly flush so that no handle or memory problems may occure.

However I am a bit concerned about Image-creation and deletion time. I create images with Component.createImage() - and I don’t know wbout the internal overhead.
If a Gradient is only painted 5 times, is it worth caching it - or is createImage() simply too expensive.

lg Clemens

#9

createImage is rather expensive… but why do you “delete” it at all? You can just draw over it.

Well, depends on what you want to do with it (feel free to be specific). Say you have some background with lots of gradient stuff. Then you could use a pool of tiles, which are overwritten column-wise on demand. Eg if it’s only scrolling horizontally you’ll get the most performance out of it if you use rectangular tiles like 8x256 (tile drawing happens more often, but there is less to draw… therefore the worst case is less bad).

#10

Well, its not for a game - it rather for a gui but I asked here since here is the location where the real java2d-professionals meet (and sometimes even guys from the java2d team have a look!).

The whole thing works quite good except when the user resizes the gui and many components change their size at once - than tons of garbage-cache-elements apear that are only used once.

But beside this fact ot works wonderful (even with java-1.1 and drawLine gradients :wink: ) - thanks for all the tipps and knowledge!

Thanks a lot, lg Clemens