Performance and scalability wise we have seen very good
results, though Gabriel reported a slowdown in the specific
case of SDE. That slowdown has not been analyzed unfortunately
and we have no clue on how and why this happened.
We hope that by applying the patches we'll get more
feedback both on the correctness of the patch and its
performance characteristics.I was also wondering if the patch could be bent for usage
in desktop apps. For Swing apps I'd say no, for the reason
that drawing directly on the video card memory via the
Graphics2D provided by the Swing components should be the
fastest approach, however last time I checked uDig was donig
an image copying dance to bridge between java2d and SWT
so in some form the patch could be useful to uDig as well.
Not copying exactly; we construct a buffered image around a block of
memory already handled by SWT. And then let the java API draw directly
into it ... so I agree it should be a speed up.
One thing I would like to ask at a high level is "where" the rendering
starts from? Is this the GridCoverageRenderer? Which for a while uDig
was using directly ... Are we rending a GridCoverage that is already
in memory; or does this only work when you have created that dummy
feature with a GridCoverageReader as one of the attributes ...
That will require some direct interest from the uDig developers though, as we don't know exactly what is needed
to operate in that enviroment (and whether there is a clear
win or not by using the same techniques that proved to
be successfull in a server side environment).
I am confident there will be a clear win; I may need some hand holding
to hook it up.
The only other concern is that the uDig is stuck back on the stable
branch at the moment. Does this patch apply to the stable branch?
Well, let me know if it's ok to apply the patch
+1 (although I would request an IRC chat when making the transition please)
Jody