Map to Image Export creates bad images

Frank Gasdorf added a comment - 17/Aug/11 5:23 AM Tried with udig-1.1.1 and the exported picture is fine! Tested both, udig-1.2.2 Release x86 and x86_64 : exported pictures are like shown in Map-TopLevel-Fill.png and Map-TopLevel-noFill.png

Pat Pelletier added a comment - 26/Sep/11 11:59 AM I have been experiencing the same problem. I have a point SHP file over a tif image. When I try the Map to Image export, I can see the tiff image, but not the data points on top. Please keep in mind that I am a beginner to uDig and could be doing something wrong. I am using udig-1.2.2.

Frank Gasdorf added a comment - 07/Dec/11 5:55 AM Right know it seems to me, that the problem has its source in the Shapefile-Layer . If the shapefile layer is not active (not visible) the export works and transparencies for all other layers are correct. In addition to that behavior the colors are not correct for shapefile-layers (white fill is getting grey, dark green is lighten up and light green is getting darker).

Frazer Jones added a comment - 19/Jan/12 1:10 PM Tried to print (and also export to image) in all versions from 1.3.1 to 1.2.2. The results were all negative as above. Udig-1.2.1 works fine. I am running Win XP.

Panagiotis Skintzos added a comment - 23/Jan/12 2:05 PM Same problem with WFS layer.

Frank Gasdorf added a comment - 06/Mar/12 4:14 AM created a pull request to solve this issue : https://github.com/uDig/udig-platform/pull/102

Andrea Antonello added a comment - 07/Mar/12 12:47 AM Hi Frank, thanks for the patch. You really are saying that it got black because the panel was wrongly drawn black? :)

Frank Gasdorf added a comment - 07/Mar/12 12:50 PM - edited Andrea, yeah, I assumed that the problem came from the graphic element itself (BufferedImage TYPE_INT_RGB vs. TYPE_INT_ARGB), but its not. I've no clue, why the method calls setBackground() and clear() are in this class, maybe rendering optimizations for update events with a ReferencedEnvelope? Do you think that the problem is coming from somewhere else? Right now I'm not sure why the MapViewer haven't had any problems with shapefiles. My guess was, both Image Exporter and MapViewer uses the same rendering subsystem with the same registered Renderers from extension registry. But my guess seems to be wrong. Properly the result of rendering differ because of different Hints for accessing RendererFactories (with its metrics) or droperly the different RendereContext's? Could anybody help with better knowledge of rendering architecture?

Jody Garnett added a comment - 14/Apr/12 4:24 AM Update from email ... BasicFeatureRenderer trying to solve one problem (clearing a small area that needs and update) in the wrong section of code. The Renderer API render(Graphics2D, ReferencedEnvelope, IProgressMonitor) method is used in three situations: a) Renderer render(IProgressMonitor) - which creates a new raster to hold the contents of the layer, and then calls renderer( Graphics2D, … ) etc to fill it with content b) ApplicationGIS drawMap which uses the renderer( Graphics2D , … ) method directly to draw every layer into the same graphics So to fix this issue we need to move the "clearRectangle" into one of two spots (not sure which yet). It could be done in the layer.refresh( … ) method; or in the renderer( IProgressMonitor ) method. Aside: Moovida and I also had a bit of fun checking how the map background colour was passed around the system. The Black colour mentioned in your bug report was confusing - I suspect that when ApplicationGIS drawMap makes a copy of the original Map it may be failing to copy the background colour over?

Jody Garnett added a comment - 14/Apr/12 5:02 AM I have pushed up a fix for testing. While I have stepped through the code with a debugger so I am confident what is going on more testing is needed :-)