Re: [Geotools-devel] Re: RenderingResolution question and a first (dumb) speed comparison

[Martin D. <mar...@te...>]

Andrea Aime a =E9crit:
>>The resolution is always computed in meters, even if the data are in
>>lat/long. This is why the error appears greater at high latitude when
>>the rendering CS is not a projected one. Of course, I can revisit this
>>issue and compute the resolution in degrees as well, but I'm not sure i=
f
>>it make a lot of sense.
>=20
>=20
> Uhm... gis people are used to look at unprojected data since ArcView
> could not reproject data (or most peple didn't know how to do it).
> Moreover, it's faster, so I think it's worth having...

Sure. I will try to think about how to do this.



>>Renderer.setRenderingHint(Hints.FINEST_RESOLUTION, new Float(0.0625));
>>Renderer.setRenderingHint(Hints.MINIMUM_RESOLUTION, new Float(2));
>=20
>=20
> Ok, a bit better now, but still not acceptable at higher latitudes.

You can disable completly the decimation with:

Renderer.setRenderingHint(Hints.FINEST_RESOLUTION,  null);
Renderer.setRenderingHint(Hints.MINIMUM_RESOLUTION, null);




> As far as the j2d renderer is concerned: it takes from 2 to 6 seconds t=
o perform the zoom,=3D20
> once zoomed the redrawing time of a quarter of the whole displayed area=
 is good (0.7 seconds).
> But since the whole display is worst case I guess, it seems that if the=
 SimpleMapPanel
> allowed for zoom, the lite renderer whould be up to three times faster =
than the
> j2d one.

Maybe. It may be worth a try.

When a zoom is performed, the j2d renderer clip the polygons before to=20
renderer them. This is why it take longer the first time the zoom is=20
applied. This clip is complementary to the clip performed by Java2D: it=20
clip an area bigger than the area to be painted, in order to avoid the=20
need for a new clip if the user translate or zoom out a little bit.=20
Java2D then perform the remaining clip. The goal of the first clip is to=20
reduces the amount of data to be given to Java2D. It would probably not=20
make a big difference if the map is made of a lot of small polygons. But=20
if it is made of one or few big polygon (for example one big polygon for=20
the whole mediteranean), then may own test suggested that it help,=20
especially with very strong zoom.

The final result is that the j2d renderer should sent less data to=20
Java2D than a renderer without its own clipping. The difference is more=20
visible if we render many time the same zoomed area, since the cache=20
stores the clipped area only.



>>isoline =3D new JTSIsoline(0);
>>isolone.add(geometry);
>=20
>=20
> Does not help, the time is spent in the rendered isoline constructor,
> where the isoline mean resolution is computed for the first time (thus,
> calling a whole lot of times the ortodromic distance calculation)

It is related to the first issue in this mail (decimation more aparent=20
at high latitude). The fix for those 2 issues is to compute "distances"=20
in degrees. This is not a real distance then, but I will try to hide=20
this fact from user's eyes.


	Regards,

		Martin.