Hi,
I was thinking about the idea of having a custom rendering
path for the raster images.
Having a separate path would sure provide a speedup, but I
was thinking that we can probably get a more general speedup
by integrating it into the main chain instead.
The idea is as follows:
- if the map context contains a coverage as the first layer,
remove it from the context and render it with the fast
path. We end up with a RenderedImage, which is also the
final result if we don't need to draw anything else.
- if the map context contains more layers, or if we need
to apply a layout, we take the RenderedImage, turn it
into a BufferedImage by creating a writable raster out
of the RendereredImage (just like it's done in the
workaround for the JPEG native image writer not working
with translated images), and from there we go and
do business as usual
This should still provide a speedup, but it is of more general
application and should speed up also the common case of
multilayer map with a raster layer in the background
What do you think, would it work?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
What happens if you have 2 or more coverages in the map context?
sophia
On Tue, Dec 22, 2009 at 8:07 AM, Andrea Aime <aaime@anonymised.com1501…> wrote:
Hi,
I was thinking about the idea of having a custom rendering
path for the raster images.
Having a separate path would sure provide a speedup, but I
was thinking that we can probably get a more general speedup
by integrating it into the main chain instead.
The idea is as follows:
- if the map context contains a coverage as the first layer,
remove it from the context and render it with the fast
path. We end up with a RenderedImage, which is also the
final result if we don’t need to draw anything else.
- if the map context contains more layers, or if we need
to apply a layout, we take the RenderedImage, turn it
into a BufferedImage by creating a writable raster out
of the RendereredImage (just like it’s done in the
workaround for the JPEG native image writer not working
with translated images), and from there we go and
do business as usual
This should still provide a speedup, but it is of more general
application and should speed up also the common case of
multilayer map with a raster layer in the background
What do you think, would it work?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon’s best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Well its about time, where was this idea before, I have been having a tough time with GWC
On Tue, Dec 22, 2009 at 7:33 PM, sophia parafina <creta.kano@anonymised.com> wrote:
What happens if you have 2 or more coverages in the map context?
sophia
On Tue, Dec 22, 2009 at 8:07 AM, Andrea Aime <aaime@anonymised.com> wrote:
Hi,
I was thinking about the idea of having a custom rendering
path for the raster images.
Having a separate path would sure provide a speedup, but I
was thinking that we can probably get a more general speedup
by integrating it into the main chain instead.
The idea is as follows:
- if the map context contains a coverage as the first layer,
remove it from the context and render it with the fast
path. We end up with a RenderedImage, which is also the
final result if we don’t need to draw anything else.
- if the map context contains more layers, or if we need
to apply a layout, we take the RenderedImage, turn it
into a BufferedImage by creating a writable raster out
of the RendereredImage (just like it’s done in the
workaround for the JPEG native image writer not working
with translated images), and from there we go and
do business as usual
This should still provide a speedup, but it is of more general
application and should speed up also the common case of
multilayer map with a raster layer in the background
What do you think, would it work?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon’s best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon’s best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
I.R
sophia parafina ha scritto:
What happens if you have 2 or more coverages in the map context?
In general, the others would be drawn with the current method, that
incurs in a scalability issue (synchronization deep in the java2d
libraries).
However, my guess is that at most you'll end up piling a group
of coverages at the bottom of the map context, and add all of the
vector layers on top of it.
If it is so, we could have the code loop over the layers bottom
to top and try to use an optimized path as long as the next
layer is still a coverage.
I guess, but I'm not sure, that we can perform some fast JAI
image composition without going down in java2d as long as we
just need to merge together coverages.
Out of curiosity, what is the common case of mixing multiple
coverages in a single result?
One that comes to mind for me is depicting a DEM using a colormap
driven base layer and a aspect layer that is drawn on top of it,
grayscale with partial transparency, to provide the illusion of
shadows
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yes, that’s one common use case, the other is the before and after use case with a swipe tool. You can compare the before and after using a tool that swipes between the two coverages.
On Tue, Dec 22, 2009 at 8:39 AM, Andrea Aime <aaime@anonymised.com> wrote:
sophia parafina ha scritto:
What happens if you have 2 or more coverages in the map context?
In general, the others would be drawn with the current method, that
incurs in a scalability issue (synchronization deep in the java2d
libraries).
However, my guess is that at most you’ll end up piling a group
of coverages at the bottom of the map context, and add all of the
vector layers on top of it.
If it is so, we could have the code loop over the layers bottom
to top and try to use an optimized path as long as the next
layer is still a coverage.
I guess, but I’m not sure, that we can perform some fast JAI
image composition without going down in java2d as long as we
just need to merge together coverages.
Out of curiosity, what is the common case of mixing multiple
coverages in a single result?
One that comes to mind for me is depicting a DEM using a colormap
driven base layer and a aspect layer that is drawn on top of it,
grayscale with partial transparency, to provide the illusion of
shadows
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Wouldn’t the client do the swiping in this case (ie, fetch both coverages as independent images and handle the variation in transparency client-side?)