Hello Stefan, hello Ugo,

Ugo wrote:
> The coordinates are converted to integers here by using a
> java.awt.Polygon. Bad idea. I replaced this by a
java.awt.geom.GeneralPath.
>
>
>>> So, what's the bad idea here, to use the awt.Polygon or to convert
to ints?
>>>

In terms of precision. You simply lose digits if your
make 3 out (int)3.1415. And in terms of speed it should make a
difference. The data is pressed thru java.awt.geom.AffineTransform s
afterwards which in result converts the integers back to floats/doubles.
You do rounding early in the rendering pipe. IMHO is that a bad idea.
Rounding  itself is done by Java2D at the end of the pipe anyway.

> See the screen shots before.png [1] and after.png [2]
>
>>> To be honest, I find difficult to compare the two images below,
because they are
>>> essentially different. (What do I have to look for?)

They are not so different as you might think. They are essentially
the same section of the map exported into the PrintLayoutPlugin.
The slightly offset an little different scale are only in the Plugin.
But you are. I should both hole scenes to SVG. That would be
a better comparison. I'll do it and send the links to the list..


Stefan Steiniger wrote:
> but i also wonder like Ugo if the current realization is faster than 
> your changes.

That has to be tested.

> So for instance we should compare by expeorting to svg if the number of 
> points is reduced by the current renderer. If yes, this will of course 
> give speed improvements for large pieces of data. Then we should make a 
> second printer renderer.

The 'number' of points is unchanged. It's the presion that changed.
The idea behind java.awt.Graphics(2D) is to have the ability of changing
the backend of the rendering without changing the rendering path itself.
If you render to the GUI a special Graphics2D comes from Java2D/Swing
If you render to printer a specialized one comes for the printer,
if you wan't to do SVG Batik has one four you.

Surely you may write 'optimized' rendering paths for different backends,
but this replicated inner logic and you're in charge of reproducing
the results correctly.

Ugo wrote:
>>> On the other hand, one should be able to plug in another renderer, for 
>>> using 
>>> when high quality rendering is needed (the case of printing and svg) and I 
>>> believe SVG does accept floats too (but I'm not sure).

That is a misconception of yours. look at [1] section <number>

greets, Sascha

[1] http://www.w3.org/TR/SVG/types.html

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to