| Re: [udig-devel] Re: [Geotools-devel] Rendering and UDIG -- Sanity Check |
James Macgill a écrit :
- It generalize the geometry (i.e. apply a decimation) according the current scale *before* to project the coordinates on the fly. Concequently, there is much less points to transform --> faster rendering.how do you do that? I would immagine that it is very hard to know how far apart two points will end up before re projecting in order to know if they will be coincident.
Right. It is an approximation working like that:
- In J2D renderer, any geometry can be broke in an arbitrary amount
of piece. For example a Polygon, while it appears as one piece on
the screen, may appears as 4 linked LineString for J2D renderer.
- The purpose of that is... Geometry tiling!! As you see, even if
J2D renderer do not yet take advantage of geometry tiling, it was
designed with this goal in mind since a long time.
- Each LineString should cover a raisonably small area (e.g. 1x1
degree). No matter how big is the Polygon, it can be broken
in J2D Renderer memory as a linked list of LineString covering
a 1x1 degree width tile each.
- J2D renderer assumes that each tile is small enough so that earth
curvature do not become too important.
- Before decimating the points, in compute the rendering resolution
(i.e. the distance between two points in the rendering CRS units),
and transform this distance in the underlying data CRS units. The
transformation is applied at the center of the tile.
- The LineString now performs the decimation using this distance
expressed in its native CRS units. It assumes that this distance
is constant every where in this tile. This is wrong if the tile is
too big, but a good approximation if the Geometry were correctly
tiles in tiles small enough.
- The process is repeated for each tiles.
Does it make sense? (so yes, J2D renderer already support tiled
Geometries for more than one year! But this capability is not yet
leveraged, probably because its API really need to be simplified and a
PointArray implementation still necessary to make it usefull).
One cirtiesm of j2d was that it used floats instead of doubles, perhaps doubles are only needed some of the time?
This is one more issue.'double' precision is not required at all step of the rendering chain. It is completly useless on the very end of the rendering chains (nobody will see the difference between a pixel at coordinates 10.00000000001 and 10.000000000002). It is important on the underlying *data* side, but not when the data coordinates has been transformed in pixel coordinates. At this stage, it may even been in the way since Java2D work with float coordinates anyway. After all, current screen are only 1000x1000 pixel width, so even a 'short' would be enough!
So the 'double' precision issue raise at the step where a data coordinates is transformed in pixel coordinates. I may have an idea about how to handle this, but need more though.
Martin.