I had tried both ways,
-one synchronized renderer object and
-renderer object per thread...
and I am not satisfied by neither one...
I was willing to make some kind of rendering object pooling, but as I
understand now, it will not give any performance advantage...
IMHO, the optimum solution is to write a WWJRenderer engine, which render
directly to OpenGL drawable context of the WWJ..
unfortunately, I don't have the experience to do that myself... at least now,
Andrea Aime <[EMAIL PROTECTED]> wrote: Ahmad Al-Obaidy ha scritto:
> I working to integrate geotools with WWJ (open source Google earth
> written in Java)
>
> you can read about the integration in this thread
> http://forum.worldwindcentral.com/showthread.php?t=16651
>
> Currently, I am using StreamingRenderer, but I think I should switch to
> something else.
>
> The renderer should be thread-safe and give performance advantages for
> subsequent paint calls.
>
> what is your recommendations?
The only working renderer in GeoTools at the moment is
StreamingRenderer, so the hard suggestion would be to write your own.
What I can try to do, is to provide suggestions on how to get the most
out of streaming renderer instead.
I've heard of thread safety issues with StreamingRenderer, yet in
GeoServer load tests never suggested the presence of one, I'd be
interested in having a hard test showing the issues.
What GeoServer does is to use a different StreamingRenderer object
for each thread of execution. Is this not applicable to your case, that
is, do you have any hard reason to use the same StreamingRenderer object
from different threads?
If you have ways to break multiple StreamingRenderer objects operating
in differen threads I'd like to have a simple, isolated test program
to debug it.
Performance wise, StreamingRenderer is designed to work with low memory
consuption, so it does not cache anything. The first thing I'd suggest
is that you give a try at ShapefileRenderer if you're rendering
shapefile, since it is expecially optimized for that case, and falls
back on StreamingRenderer for all other cases.
Second this, pass these hints to the renderer before using it:
Map rendererParams = new HashMap();
rendererParams.put("optimizedDataLoadingEnabled", new Boolean(true));
renderer.setRendererHints(rendererParams);
They will speed up rendering for the cases where you have lots
of attribute that aren't used during the styling process.
Beyond that, if you're dealing with a limited amount of data that can
fit into memory, you can use an old class I sent to this mailing
list to deal with that case. It has never been committed to gt2
because I have no use for it, so it would need someone to maintain it.
It's contained in this thread:
http://www.nabble.com/Render-with-gt2.3.1-to10129502.html#a10129502
In any case, that class is imho of little value, because it'll
force all the data into memory. A better approach has been developed
by a SoC student last summer, and indexed, caching feature source
wrapper that can get rid of excess data and thus only cache
the part of data you're using now. Of course it's not fully tested,
but the concept was promising, so it would be great if you could
pick it up.
Unfortunately I have no idea where that has been committed, I only
found the wiki page related to it:
http://geotools.codehaus.org/SoC+2007+Caching+data
I've cc'ed Jody and Ian, maybe they do know where to find it.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
