Skip to main content

render speed

12 replies [Last post]
jcmeira
Offline
Joined: 2003-08-02
Points: 0

The render speed should be increment when the width of BasicStroke > 1.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
detorres
Offline
Joined: 2003-07-07
Points: 0

I guess I'm lucky I haven't been affected by any of these bugs.

I can say that I am seeing a ***huge*** increase in performance for my Java2D application which uses AffineTransforms on images (as of 1.6.0-ea-b21).

Thanks!

-Andy

campbell
Offline
Joined: 2003-06-24
Points: 0

> Please have a look at the following unevaluated issue
> (there are a few similar issues, but this is the one
> I am experiencing on a regular basis):
> Buffer Overflow / SIG_SEGV hot spot error in
> Graphics2D.draw(GeneralPath)
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=617
> 8847
>

Hi Sebastian,

Have you tried any of the Mustang snapshots yet? It appears that this issue (probably a duplicate of 5089985) was fixed in 6.0-b14. Could you please download the latest Mustang snapshot and verify the fix?

Thanks,
Chris

yguy
Offline
Joined: 2003-08-23
Points: 0

Hi Chris,
> Could you please
> download the latest Mustang snapshot and verify the
> fix?

I just did so and after some quick testing I must really say that I am impressed - it seems that a lot of annoying java2d bugs (some of them have been there since 1.2) have been fixed! I could identify 4 fixed issues just by playing with our application!
The snapshot release seems to fix the issue I mentioned, I wasn't able to reproduce the mentioned core dumps anymore with my quick tests.

Many of those bugs have been there for a long time - any chance that these fixes will be backported to previous versions (at least to 1.4 and 1.5 since 1.4 is what most of our customers are using and they will probably do so for some time)?

Regards, Sebastian

jcmeira
Offline
Joined: 2003-08-02
Points: 0

Why not reuse the object GeneralPath in BasicStroke,
BasicStroke implements Stroke{
........
........
private class FillAdapter implements PathConsumer {
boolean closed;
---->GeneralPath path;<----
.....
.....
}
It could be a field of BasicSroke

jcmeira
Offline
Joined: 2003-08-02
Points: 0

Don't forget the low speed for transparent objects

campbell
Offline
Joined: 2003-06-24
Points: 0

We've been exploring some ways to improve wide (> 1 pixel) line performance. We know that low performance of this case is really impacting many apps out there that want to display complex data, such as interactive maps. We think there are a few simple optimizations that can be made to speed up the simple cases (no round joins or end caps), but we also have some ideas to leverage hardware for even the more complex cases (those that do have round elements). Not sure how much we can get done in the Mustang timeframe, but rest assured we're looking into it.

Thanks,
Chris
Java 2D Team

yguy
Offline
Joined: 2003-08-23
Points: 0

Hi Chris,
I like the fact that the Java 2D Team is trying to improve performance, although I am quite satisfied with the current performance (my company is developing one of the huge commercial graph libraries and we are quite experienced Java2D users).
However I would appreciate it much more if they took the time to fix those (not too many) VERY SERIOUS bugs, because otherwise people might stop using Java 2D at all.
I am talking about bugs that crash the virtual machine in not very unusual use-cases (in fact I am seeing these crashes on a daily basis). The problem is you can hardly do anything against it if your program/application/webserver simply crashes with a core dump because of an internal hotspot error that originates from the sun.dc.pr packages.
Please have a look at the following unevaluated issue (there are a few similar issues, but this is the one I am experiencing on a regular basis):
Buffer Overflow / SIG_SEGV hot spot error in Graphics2D.draw(GeneralPath)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178847

The Graphics2D API is truely powerful and can be used to render beautiful graphics easily, however if you cannot use AA and GeneralPaths without experiencing a hotspot crash now and then, this is not only annoying but sad.

(Maybe we will have to find a way to exploit the buffer overflow and execute malicious code so that we have a true security issue that we can exploit in an applet. I guess then this issue will be addressed more quickly.)

Kind regards and thanks for reading,
Sebastian Mueller
yFiles Development Team

mthornton
Offline
Joined: 2003-06-10
Points: 0

Bug 4265778 could do with fixing as well.

campbell
Offline
Joined: 2003-06-24
Points: 0

> Bug 4265778 could do with fixing as well.

Hi Mark,

This is a high priority item for us in Mustang as well. Stay tuned.

Thanks,
Chris

jcmeira
Offline
Joined: 2003-08-02
Points: 0

I have to write a aplicaction for draw maps and I have render a lot of lines (about 200000) lines with BasicStroke(2) and with GradientPaint too.
The performance is very, very slow.
I am think in change to C# because I don´t let that performance, or write in C++ the paint method.

mthornton
Offline
Joined: 2003-06-10
Points: 0

> I am think in change to C# because I don´t let that
> performance, or write in C++ the paint method.

Don't bother. I believe both of these (especially C#) have the same problem.

With most current graphics cards, to accelerate wide lines you use the 3D polygon filling capability. You can either do this yourself using JOGL or wait for the Java2D pipe line to add an optimisation for this case.

For now a better approach is to cache the rendered map because the map doesn't change often. Having cached the rendering you can afford to be even more expensive and use anti-aliassing which makes the result look a lot better.

Finally it may help to limit the number of points on each wide line. When using Windows GDI from C++, lines with more than about 200 points were rendered very slowly. The coastline of Norway being a particularly bad example.

Oh, and a mere 200000 lines .... I have maps with millions of lines (with many points on each). Even for a small country like Portugal I have 280000 for the roads alone, never mind other features like coast, lakes, rivers, etc.

mgrev
Offline
Joined: 2003-08-12
Points: 0

Good one.

+1

I would say that just about every Stroke except the BasicStroke(1f) is very slow and are in need for some well needed overhaul.

We actually can't use it in our Calendar component (ok, you can, but we would recommend against it) since it bogs down the rendering path too much.

I think this will be one "will not fix" though, since the API today makes it difficult to accelerate in a generic way. Same as a sub classes of GradientPaint or your own implementation of a cool Paint. It wasn't meant to be accelerated when created.

I might be possible to tune the software path though?

Cheers,
Mikael Grev
migcalendar.miginfocom.com