Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
I've been reading the StreamingRenderer trying to understand how the
layer's drawing process works.
When the StreamingRenderer draws the layer[1] it uses the
Graphics2D.drawImage method. Wouldn't be better to use the
Graphics2D.drawRenderedImage to apply the transformation (and get better
performance?).
Who is the developer of StreamingRenderer?
[1]
-- start code StreamingRenderer code (line 1585)
// graphics.setTransform( new AffineTransform() );
for (int t = 0; t n_lfts; t++) {
if (fts_array[t].myImage != null) // this is the case for the
// first one (ie.
// fts_array[t].graphics ==
// graphics)
{
graphics.drawImage(fts_array[t].myImage, 0, 0, null);
fts_array[t].myImage.flush();
fts_array[t].graphics.dispose();
}
}
-- end code
On mar, 2007-12-11 at 13:50 -0800, Jody Garnett wrote:
Okay; so JPanel does double buffering by default (so your paint method
is being passed a Graphics object that is backed onto a BuferedImage -
check it out in a debugger). Needless to say this is not what you want
for performance...
Have a read of this:
- http://www.exampledepot.com/egs/java.awt.image/VolImage.html
Now there is a good chance I am leading you down the garden path here;
performance tuning is a difficult balance. Please try rendering to a
VolatileImage and let it me know if it works in your situation. I know
it does wonders for doing the usual range of JAI activities; but
resampling down onto disk may stretch the limits.
The source code for JAI is online; you may want to look exactly at what
DisplayJAI is doing.
Cheers,
Jody
I append the full source code[1] but the painting part is:
private class PanelMap extends JPanel {
@Override
public void paint(Graphics g) {
try {
Graphics2D g2d = (Graphics2D) g;
Rectangle rectangle = new Rectangle(getSize());
//System.out.println(Map size (px): + rectangle.height
+ x + rectangle.width);
renderer.paint(g2d, rectangle,
mapContext.getLayerBounds());
} catch (IOException ex) {
Logger.getLogger(PanelGeoMap.class.getName()).log(Level.SEVERE,
null, ex);
}
}
}
I override the JPanel's paint method. PanelMap is inside a JScrollPane
and the renderer, in theory, only have to draw the visible viewport.
--
Diego Fdez. Durán [EMAIL PROTECTED] | http://www.goedi.net
GPG : 925C 9A21 7A11 3B13 6E43 50DB F579 D119 90D2 66BB
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Geotools-gt2-users mailing list
Geotools-gt2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
Simone Giannecchini ha scritto: Ciao Diego (again :-) ), please, read below On Dec 12, 2007 1:05 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote: I've been reading the StreamingRenderer trying to understand how the layer's drawing process works. When the StreamingRenderer draws the layer[1] it uses the Graphics2D.drawImage method. Wouldn't be better to use the Graphics2D.drawRenderedImage to apply the transformation (and get better performance?). The images that we use in the streaming renderer are bufferedimages which are untiled. They are intrinsically in-memory hence using drawrenderimage would not bring any performance speed up. drawRenderedImage should be used when drawing tiled images like PlanarImage subclasses. Of course IMHO :-) Well, in GeoServer we are encoding everything against a BufferedImage (since we are supposed to work in a headless environment) but that is not the case of Diego, he's doing a Swing app as far as I understand, right? Cheers Andrea - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
Exaclty, that's the point. I think what diego needs is something different from what the StreamingRenderer is supposed to do. This is why I am asking details about what he needs to do. If he has some specific needs I can drop some ideas that would help him to get very high perfomances even with enormous coverage. You have seen a few time the experimental viewers I have for coverage with enabled pyramids, they are really fast even if the coveerage are big. Simone. On Dec 12, 2007 3:04 PM, Andrea Aime [EMAIL PROTECTED] wrote: Simone Giannecchini ha scritto: Ciao Diego (again :-) ), please, read below On Dec 12, 2007 1:05 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote: I've been reading the StreamingRenderer trying to understand how the layer's drawing process works. When the StreamingRenderer draws the layer[1] it uses the Graphics2D.drawImage method. Wouldn't be better to use the Graphics2D.drawRenderedImage to apply the transformation (and get better performance?). The images that we use in the streaming renderer are bufferedimages which are untiled. They are intrinsically in-memory hence using drawrenderimage would not bring any performance speed up. drawRenderedImage should be used when drawing tiled images like PlanarImage subclasses. Of course IMHO :-) Well, in GeoServer we are encoding everything against a BufferedImage (since we are supposed to work in a headless environment) but that is not the case of Diego, he's doing a Swing app as far as I understand, right? Cheers Andrea -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
Ciao Diego,
yeah, it's me again :-).
I am wondering about your goals
Could you describe exaclty what you are trying to do in terms of
sources of data and suported features? I could try and give some
directions as well as sharing some code that I have that would be
really handy for you. It does make use of internal pyramids as well as
some good old copy area call.
Simone.
On Dec 12, 2007 1:05 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote:
I've been reading the StreamingRenderer trying to understand how the
layer's drawing process works.
When the StreamingRenderer draws the layer[1] it uses the
Graphics2D.drawImage method. Wouldn't be better to use the
Graphics2D.drawRenderedImage to apply the transformation (and get better
performance?).
Who is the developer of StreamingRenderer?
[1]
-- start code StreamingRenderer code (line 1585)
// graphics.setTransform( new AffineTransform() );
for (int t = 0; t n_lfts; t++) {
if (fts_array[t].myImage != null) // this is the case for the
// first one (ie.
// fts_array[t].graphics ==
// graphics)
{
graphics.drawImage(fts_array[t].myImage, 0, 0, null);
fts_array[t].myImage.flush();
fts_array[t].graphics.dispose();
}
}
-- end code
On mar, 2007-12-11 at 13:50 -0800, Jody Garnett wrote:
Okay; so JPanel does double buffering by default (so your paint method
is being passed a Graphics object that is backed onto a BuferedImage -
check it out in a debugger). Needless to say this is not what you want
for performance...
Have a read of this:
- http://www.exampledepot.com/egs/java.awt.image/VolImage.html
Now there is a good chance I am leading you down the garden path here;
performance tuning is a difficult balance. Please try rendering to a
VolatileImage and let it me know if it works in your situation. I know
it does wonders for doing the usual range of JAI activities; but
resampling down onto disk may stretch the limits.
The source code for JAI is online; you may want to look exactly at what
DisplayJAI is doing.
Cheers,
Jody
I append the full source code[1] but the painting part is:
private class PanelMap extends JPanel {
@Override
public void paint(Graphics g) {
try {
Graphics2D g2d = (Graphics2D) g;
Rectangle rectangle = new Rectangle(getSize());
//System.out.println(Map size (px): + rectangle.height
+ x + rectangle.width);
renderer.paint(g2d, rectangle,
mapContext.getLayerBounds());
} catch (IOException ex) {
Logger.getLogger(PanelGeoMap.class.getName()).log(Level.SEVERE,
null, ex);
}
}
}
I override the JPanel's paint method. PanelMap is inside a JScrollPane
and the renderer, in theory, only have to draw the visible viewport.
--
Diego Fdez. Durán [EMAIL PROTECTED] | http://www.goedi.net
GPG : 925C 9A21 7A11 3B13 6E43 50DB F579 D119 90D2 66BB
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Geotools-gt2-users mailing list
Geotools-gt2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
--
---
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 333 8128928
http://www.geo-solutions.it
---
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Geotools-gt2-users mailing list
Geotools-gt2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
Hi all: I'll try to describe my project: - I'm developing a Swing application that will show a really BIG map (150k x 100k px). - I need to navigate through the image and the navigation speed is critical. - Even though the user must be allowed to zoom in an out the map, the maximum resolution will be the default (and what the user will be using normally). - The user must be allowed to load layers above the raster (ex. using shapefiles). - The raster files (index shapefile + geotiff) are stored in the local (SCSI) HD. The storage capacity isn't a problem. - The app must run in Debian GNU/Linux. On mié, 2007-12-12 at 15:11 +0100, Simone Giannecchini wrote: Exaclty, that's the point. I think what diego needs is something different from what the StreamingRenderer is supposed to do. This is why I am asking details about what he needs to do. If he has some specific needs I can drop some ideas that would help him to get very high perfomances even with enormous coverage. You have seen a few time the experimental viewers I have for coverage with enabled pyramids, they are really fast even if the coveerage are big. Simone. On Dec 12, 2007 3:04 PM, Andrea Aime [EMAIL PROTECTED] wrote: Simone Giannecchini ha scritto: Ciao Diego (again :-) ), please, read below On Dec 12, 2007 1:05 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote: I've been reading the StreamingRenderer trying to understand how the layer's drawing process works. When the StreamingRenderer draws the layer[1] it uses the Graphics2D.drawImage method. Wouldn't be better to use the Graphics2D.drawRenderedImage to apply the transformation (and get better performance?). The images that we use in the streaming renderer are bufferedimages which are untiled. They are intrinsically in-memory hence using drawrenderimage would not bring any performance speed up. drawRenderedImage should be used when drawing tiled images like PlanarImage subclasses. Of course IMHO :-) Well, in GeoServer we are encoding everything against a BufferedImage (since we are supposed to work in a headless environment) but that is not the case of Diego, he's doing a Swing app as far as I understand, right? Cheers Andrea -- Diego Fdez. Durán [EMAIL PROTECTED] | http://www.goedi.net GPG : 925C 9A21 7A11 3B13 6E43 50DB F579 D119 90D2 66BB signature.asc Description: Esta parte del mensaje está firmada digitalmente - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
Well, If I get things right, you have a raster background, which you want to visit at fixedresolutionlevels. You also want to overlay features on top of this. Well, I would suggest a simple thing. Use the streaming renderer to render the features and then overlay this on top of the background image. This way you can trick as much as you want with the coverage without impacting features. I would probablyuse two different backbuffers, one where you draw the coverage, one where you draw the results of the streaming renderer for features. This way you can avoid a lot of unneded code for the coverage. I might be more specific, but I don't have much time, sorry. Simone. On Dec 12, 2007 3:44 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote: Hi all: I'll try to describe my project: - I'm developing a Swing application that will show a really BIG map (150k x 100k px). - I need to navigate through the image and the navigation speed is critical. - Even though the user must be allowed to zoom in an out the map, the maximum resolution will be the default (and what the user will be using normally). - The user must be allowed to load layers above the raster (ex. using shapefiles). - The raster files (index shapefile + geotiff) are stored in the local (SCSI) HD. The storage capacity isn't a problem. - The app must run in Debian GNU/Linux. On mié, 2007-12-12 at 15:11 +0100, Simone Giannecchini wrote: Exaclty, that's the point. I think what diego needs is something different from what the StreamingRenderer is supposed to do. This is why I am asking details about what he needs to do. If he has some specific needs I can drop some ideas that would help him to get very high perfomances even with enormous coverage. You have seen a few time the experimental viewers I have for coverage with enabled pyramids, they are really fast even if the coveerage are big. Simone. On Dec 12, 2007 3:04 PM, Andrea Aime [EMAIL PROTECTED] wrote: Simone Giannecchini ha scritto: Ciao Diego (again :-) ), please, read below On Dec 12, 2007 1:05 PM, Diego Fdez. Durán [EMAIL PROTECTED] wrote: I've been reading the StreamingRenderer trying to understand how the layer's drawing process works. When the StreamingRenderer draws the layer[1] it uses the Graphics2D.drawImage method. Wouldn't be better to use the Graphics2D.drawRenderedImage to apply the transformation (and get better performance?). The images that we use in the streaming renderer are bufferedimages which are untiled. They are intrinsically in-memory hence using drawrenderimage would not bring any performance speed up. drawRenderedImage should be used when drawing tiled images like PlanarImage subclasses. Of course IMHO :-) Well, in GeoServer we are encoding everything against a BufferedImage (since we are supposed to work in a headless environment) but that is not the case of Diego, he's doing a Swing app as far as I understand, right? Cheers Andrea -- Diego Fdez. Durán [EMAIL PROTECTED] | http://www.goedi.net GPG : 925C 9A21 7A11 3B13 6E43 50DB F579 D119 90D2 66BB - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] DisplayJAI vs Rendering to BufferedImage JPanel
I've followed you all down the garden path :) and it appears to be the
right path.
I've rewritten the PanelMap code using VolatileImage[1] but I can't test
it with the big map until tomorrow morning, then I'll send a report :)
P.S.- When I was doing a test with the big map in a single GeoTiff file
I've found another problem. The image is so big (92336x146887) that I
get the following error:
java.lang.NegativeArraySizeException
at java.awt.image.DataBufferByte.init(DataBufferByte.java:42)
I suppose that it's an unsigned int overflow in the DataBufferByte code
because:
map: 92336*146887 = 13562958032
uint: 2^32 = 4294967296
it's only a supposition and it isn't a problem because I'll be using
the ImageMosaic plugin.
[1]
-- start code
private class PanelMap extends JPanel {
VolatileImage vImg;
public PanelMap() {
super();
setDoubleBuffered(false);
vImg = createVolatileImage(getWidth(), getHeight());
if(vImg == null) {
System.err.println(vImage null);
}
}
/*
* OffScreen image render
*/
void renderOffscreen() {
do {
if (vImg.validate(getGraphicsConfiguration()) ==
VolatileImage.IMAGE_INCOMPATIBLE) {
// old vImg doesn't work with new GraphicsConfig;
re-create it
vImg = createVolatileImage(getWidth(), getHeight());
}
Graphics2D g = vImg.createGraphics();
/*
* Do rendering operations
*/
try {
Rectangle rectangle = new Rectangle(getSize());
System.out.println(Tamano del mapa (pixels): +
rectangle.height + x + rectangle.width);
renderer.paint(g, rectangle,
mapContext.getLayerBounds());
} catch (IOException ex) {
Logger.getLogger(PanelGeoMap.class.getName()).log(Level.SEVERE, null,
ex);
}
g.dispose();
} while (vImg.contentsLost());
}
@Override
public void paint(Graphics g) {
Graphics2D g2 = (Graphics2D) g;
if(vImg == null) {
System.err.println(paint :: vImg null);
//vImg = createVolatileImage(getWidth(), getHeight());
vImg =
g2.getDeviceConfiguration().createCompatibleVolatileImage(
getWidth(), getHeight());
}
/*
* Write image on the screen
*/
do {
int returnCode =
vImg.validate(getGraphicsConfiguration());
if (returnCode == VolatileImage.IMAGE_RESTORED) {
// Contents need to be restored
renderOffscreen(); // restore contents
} else if (returnCode ==
VolatileImage.IMAGE_INCOMPATIBLE) {
// old vImg doesn't work with new GraphicsConfig;
re-create it
vImg = createVolatileImage(getWidth(), getHeight());
renderOffscreen();
}
g.drawImage(vImg, 0, 0, this);
} while (vImg.contentsLost());
}
}
-- end code
On mar, 2007-12-11 at 13:50 -0800, Jody Garnett wrote:
Okay; so JPanel does double buffering by default (so your paint method
is being passed a Graphics object that is backed onto a BuferedImage -
check it out in a debugger). Needless to say this is not what you want
for performance...
Have a read of this:
- http://www.exampledepot.com/egs/java.awt.image/VolImage.html
Now there is a good chance I am leading you down the garden path here;
performance tuning is a difficult balance. Please try rendering to a
VolatileImage and let it me know if it works in your situation. I know
it does wonders for doing the usual range of JAI activities; but
resampling down onto disk may stretch the limits.
The source code for JAI is online; you may want to look exactly at what
DisplayJAI is doing.
Cheers,
Jody
I append the full source code[1] but the painting part is:
private class PanelMap extends JPanel {
@Override
public void paint(Graphics g) {
try {
Graphics2D g2d = (Graphics2D) g;
Rectangle rectangle = new Rectangle(getSize());
//System.out.println(Map size (px): + rectangle.height
+ x + rectangle.width);
renderer.paint(g2d, rectangle,
mapContext.getLayerBounds());
} catch (IOException ex) {
Logger.getLogger(PanelGeoMap.class.getName()).log(Level.SEVERE,
null, ex);
}
}
}
I override the JPanel's paint method. PanelMap is inside a JScrollPane
and the renderer, in theory, only
