Re: [JPP-Devel] RenderingManager modes in skyjump
Hi Geoffrey, I suspect the issues raised by Larry are central to the issues I have had with printing. In my printer plugin I have three options for printing and they each give slightly different results depending on what is being printed (scale of map, size of text and patterns etc). It is often necessary for a user to try each mode then pick the results that best suits their needs. The different rendering modes are now available in the RenderingManager, that is : public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; I now try to familiarize with Larry's Printer code. As far as I could see, scale problems also exist in SkyJUMP printer (ex. decoration elements are not displayed the same size with every option). Ideally the core renderer should do the job, but I appreciate the optimisations that are necessary for the UI may make this not easily possible. I have come across a similar problem with printing large JTables (several thousand rows) where I had to manually force the image to be fully painted for the printing process. Otherwise I found that only part of the image would actually get printed, depending on where the UI had scrolled to on the screen. I see, Hopefully, printing in the event thread will help in this kind of situation. Let me know if you have ideas to improve printing core capabilities to get a better control on how things are done in printing extensions. Michaël Whether the problem can be (economically) fixed is another problem Geoff On 10/06/2013 04:28, Michaël Michaud wrote: Hi Larry (Becker), I'm slowly progressing on this topic. I added different rendering modes in RenderingManager, Except the printing stuff, there are only a few classes where new modes are used. I tested the change on AbstractZoomTool : In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode I feel like INTERACTIVE mode gives a better feedback on large datasets Is there any motivation to have changed rendering mode to EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ? Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver
Re: [JPP-Devel] RenderingManager modes in skyjump
@Michaël, A few hints: com.isa.jump.plugin.PrintPlugIn is the UI class that uses PrinterDriver and PDFDriver to do the work. You can use PrintPlugin as is with some localization work, or you can use as an example to build your own UI class. @Geoffrey, In order to use the new print architecture you might want to use some of the pubic code in PrinterDriver after it is translated to OJ. As a minimum you might try: PrinterDriver.disableDoubleBuffering(yourLayerViewPanel); yourLayerViewPanel.getRenderingManager().setRenderingMode( RenderingManager.EXECUTE_ON_EVENT_THREAD); yourLayerViewPanel.getRenderingManager().renderAll(); yourLayerViewPanel.getRenderingManager().copyTo(graphics); yourLayerViewPanel.getRenderingManager().setRenderingMode( RenderingManager.INTERACTIVE); PrinterDriver.enableDoubleBuffering(yourLayerViewPanel); regards, Larry On Wed, Jun 12, 2013 at 4:01 PM, Michaël Michaud michael.mich...@free.frwrote: Hi Geoffrey, I suspect the issues raised by Larry are central to the issues I have had with printing. In my printer plugin I have three options for printing and they each give slightly different results depending on what is being printed (scale of map, size of text and patterns etc). It is often necessary for a user to try each mode then pick the results that best suits their needs. The different rendering modes are now available in the RenderingManager, that is : public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; I now try to familiarize with Larry's Printer code. As far as I could see, scale problems also exist in SkyJUMP printer (ex. decoration elements are not displayed the same size with every option). Ideally the core renderer should do the job, but I appreciate the optimisations that are necessary for the UI may make this not easily possible. I have come across a similar problem with printing large JTables (several thousand rows) where I had to manually force the image to be fully painted for the printing process. Otherwise I found that only part of the image would actually get printed, depending on where the UI had scrolled to on the screen. I see, Hopefully, printing in the event thread will help in this kind of situation. Let me know if you have ideas to improve printing core capabilities to get a better control on how things are done in printing extensions. Michaël Whether the problem can be (economically) fixed is another problem Geoff On 10/06/2013 04:28, Michaël Michaud wrote: Hi Larry (Becker), I'm slowly progressing on this topic. I added different rendering modes in RenderingManager, Except the printing stuff, there are only a few classes where new modes are used. I tested the change on AbstractZoomTool : In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode I feel like INTERACTIVE mode gives a better feedback on large datasets Is there any motivation to have changed rendering mode to EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ? Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I
Re: [JPP-Devel] RenderingManager modes in skyjump
Dear Michael I suspect the issues raised by Larry are central to the issues I have had with printing. In my printer plugin I have three options for printing and they each give slightly different results depending on what is being printed (scale of map, size of text and patterns etc). It is often necessary for a user to try each mode then pick the results that best suits their needs. Ideally the core renderer should do the job, but I appreciate the optimisations that are necessary for the UI may make this not easily possible. I have come across a similar problem with printing large JTables (several thousand rows) where I had to manually force the image to be fully painted for the printing process. Otherwise I found that only part of the image would actually get printed, depending on where the UI had scrolled to on the screen. Whether the problem can be (economically) fixed is another problem Geoff On 10/06/2013 04:28, Michaël Michaud wrote: Hi Larry (Becker), I'm slowly progressing on this topic. I added different rendering modes in RenderingManager, Except the printing stuff, there are only a few classes where new modes are used. I tested the change on AbstractZoomTool : In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode I feel like INTERACTIVE mode gives a better feedback on large datasets Is there any motivation to have changed rendering mode to EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ? Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver working it should be easy add the iText library which gives the direct PDF generation with layers. When testing the PDF output always determine first if it is generating true vectors by zooming in fully. Then you may also see the effects of decimation as implemented in Java2DConverter and even in java.awt.Graphics2D. That's all for now. I've rambled on enough. Let me know what else I can clarify. Regards, Larry On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi Larry (Becker), I've started pdf printer integration in openjump and the main change
Re: [JPP-Devel] RenderingManager modes in skyjump
Hi Larry (Becker), I'm slowly progressing on this topic. I added different rendering modes in RenderingManager, Except the printing stuff, there are only a few classes where new modes are used. I tested the change on AbstractZoomTool : In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode I feel like INTERACTIVE mode gives a better feedback on large datasets Is there any motivation to have changed rendering mode to EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ? Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver working it should be easy add the iText library which gives the direct PDF generation with layers. When testing the PDF output always determine first if it is generating true vectors by zooming in fully. Then you may also see the effects of decimation as implemented in Java2DConverter and even in java.awt.Graphics2D. That's all for now. I've rambled on enough. Let me know what else I can clarify. Regards, Larry On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi Larry (Becker), I've started pdf printer integration in openjump and the main change that I face is one in RenderingManager where you introduced 3 rendering mode public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; Before I port this change to OpenJUMP (maybe I'll wait after 1.6 release), I'd like to have a better vision of what problem it is supposed to solve and to know if it is related to the add of printing capabilities. Thanks for all, Michaël -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] RenderingManager modes in skyjump
Hi Michaël, I recall it is pretty subjective, but I think I used EXECUTE_ON_EVENT_THREAD to avoid over-use of threads which can spawn out of control with the mouse wheel. regards, Laarry On Sun, Jun 9, 2013 at 3:28 PM, Michaël Michaud michael.mich...@free.frwrote: Hi Larry (Becker), I'm slowly progressing on this topic. I added different rendering modes in RenderingManager, Except the printing stuff, there are only a few classes where new modes are used. I tested the change on AbstractZoomTool : In OpenJUMP, MouseWheel zoom is done on an INTERACTIVE mode In SkyJUMP, you use the EXECUTE_ON_EVENT_THREAD mode I feel like INTERACTIVE mode gives a better feedback on large datasets Is there any motivation to have changed rendering mode to EXECUTE_ON_EVENT_THREAD in SKYJump for mousewheel zoom ? Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver working it should be easy add the iText library which gives the direct PDF generation with layers. When testing the PDF output always determine first if it is generating true vectors by zooming in fully. Then you may also see the effects of decimation as implemented in Java2DConverter and even in java.awt.Graphics2D. That's all for now. I've rambled on enough. Let me know what else I can clarify. Regards, Larry On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud michael.mich...@free.fr wrote: Hi Larry (Becker), I've started pdf printer integration in openjump and the main change that I face is one in RenderingManager where you introduced 3 rendering mode public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; Before I port this change to OpenJUMP (maybe I'll wait after 1.6 release), I'd like to have a better vision of what problem it is supposed to solve and to know if it is related to the add of printing capabilities. Thanks for all, Michaël -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:http://p.sf.net/sfu/appdyn_d2d_mar
Re: [JPP-Devel] RenderingManager modes in skyjump
Hi, If you have your hands dirty already I would suggest to make some preparations for making it easier to write geospatial PDF files in the future. The essential thing to do is to capture the envelope of a map as polygon WKT and store is somewhere. For example it could be saved into a plain text file that uses the same filename base output_map_2013_03_15_neatline.txt Saving also the SRID would be a good addition but then you should ask user to give it because OpenJUMP is not projection aware. I will show later an example about how this into can be utilized. If we are saving some metadata then perhaps there could be an option to save also other metadata that can be embedded into PDF file. GDAL PDF driver page http://www.gdal.org/frmt_pdf.html is listing these metadata items: AUTHOR, CREATOR, CREATION_DATE, KEYWORDS, PRODUCER, SUBJECT, TITLE Usage example: AUTHOR=Jukka Rahkonen http://latuviitta.org; CREATOR=SkyJUMP/OpenJUMP PDF Writer CREATION_DATE=D:20121122132447+02'00' KEYWORDS=OpenJUMP, MAP PRODUCER=name of the PDF library SUBJECT=Some subject TITLE=OpenJUMP PDF Map The date format is D:MMDDHHmmSSOHH'mm' For 22 nov 2012 13:24:47 GMT+02: D:20121122132447+02'00' These metadata could also be stored into text file for the future needs but I guess that PDF libraries can also write them directly into PDF file. This page shows how some software is doing it and what it the result http://www.verypdf.com/pdfinfoeditor/pdf-metadata.html And here comes an example how the neatline metadata can be used in post-processing. First I created a PDF map from a non georeferenced tiff image with gdal_translate as gdal_translate -of PDF base.tif base.pdf We can imagine this PDF came from OpenJUMP PDF Writer. Then I draw a polygon and captured the WKT and I decided that the SRID is EPSG:4326. The following command converts the base.pdf file into geospatial PDF gdal_translate -of PDF -a_srs epsg:4326 -co NEATLINE POLYGON ((21.2660 557 42.01149896236421, 21.2660557 42.020383, 21.278203573003132 42.020383, 2 1.278203573003132 42.01149896236421, 21.2660557 42.01149896236421)) base.pdf geospat.pdf Gdalinfo about geospat.pdf confirms that it is location aware now gdalinfo geospat.pdf Driver: PDF/Geospatial PDF Files: geospat.pdf Size is 537, 393 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (21.2660546,42.02038333299) Pixel Size = (0.22664211656,-0.22664211656) Metadata: DPI=72 NEATLINE=POLYGON ((21.2660557 42.0203828,21.2660557 42.0114989623642,21.27 8203573003125 42.0114989623642,21.278203573003125 42.0203828,21.2660557 42.02038 28)) Corner Coordinates: Upper Left ( 21.2660556, 42.0203833) ( 21d15'57.80E, 42d 1'13.38N) Lower Left ( 21.2660556, 42.0114763) ( 21d15'57.80E, 42d 0'41.31N) Upper Right ( 21.2782262, 42.0203833) ( 21d16'41.61E, 42d 1'13.38N) Lower Right ( 21.2782262, 42.0114763) ( 21d16'41.61E, 42d 0'41.31N) Center ( 21.2721409, 42.0159298) ( 21d16'19.71E, 42d 0'57.35N) Band 1 Block=537x1 Type=Byte, ColorInterp=Red Band 2 Block=537x1 Type=Byte, ColorInterp=Green Band 3 Block=537x1 Type=Byte, ColorInterp=Blue This example should be taken as a demonstration which shows that it is possible to add georeferencing afterwards but not as an instruction about how to do is. Gdal_translate as used in the example is not the right tool because it is rasterizing PDF vectors in PDF to PDF conversion which is not desired. -Jukka Rahkonen- Michaël Michaud wrote: Hi Larry, All that makes sense. Thanks for the detailed answers to my last question and to the few next ones ;-) I'll keep them preciously as diving in the rendering pipeline is always a challenge for me. By the way, I already could print to pdf with your printer + openjump, but I'd to deactivate a few lines as I did not update RendererManager yet. Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a
[JPP-Devel] RenderingManager modes in skyjump
Hi Larry (Becker), I've started pdf printer integration in openjump and the main change that I face is one in RenderingManager where you introduced 3 rendering mode public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; Before I port this change to OpenJUMP (maybe I'll wait after 1.6 release), I'd like to have a better vision of what problem it is supposed to solve and to know if it is related to the add of printing capabilities. Thanks for all, Michaël -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] RenderingManager modes in skyjump
Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver working it should be easy add the iText library which gives the direct PDF generation with layers. When testing the PDF output always determine first if it is generating true vectors by zooming in fully. Then you may also see the effects of decimation as implemented in Java2DConverter and even in java.awt.Graphics2D. That's all for now. I've rambled on enough. Let me know what else I can clarify. Regards, Larry On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud michael.mich...@free.frwrote: Hi Larry (Becker), I've started pdf printer integration in openjump and the main change that I face is one in RenderingManager where you introduced 3 rendering mode public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; Before I port this change to OpenJUMP (maybe I'll wait after 1.6 release), I'd like to have a better vision of what problem it is supposed to solve and to know if it is related to the add of printing capabilities. Thanks for all, Michaël -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] RenderingManager modes in skyjump
Hi Larry, All that makes sense. Thanks for the detailed answers to my last question and to the few next ones ;-) I'll keep them preciously as diving in the rendering pipeline is always a challenge for me. By the way, I already could print to pdf with your printer + openjump, but I'd to deactivate a few lines as I did not update RendererManager yet. Michaël Hi Michaël, Thanks for starting this effort. I'll try to answer your questions as best I can. When I wrote this code four years ago, I was immersed in printer lore that I have mostly forgotten. Here are a few things that I can recall: (excuse my lecture tone, I know you are very knowledgeable on the subject of rendering) 1. Rendering for interactive display has completely different goals than rendering for printing. It is mostly an issue of responsiveness vs. quality. The JUMP render architecture, as you well know, has excellent responsiveness and an especially quick redraw capability thanks to per-layer double buffering. In this aspect it far outperforms ArcMap and many other GIS programs. While this is a positive for interactive use, it is a huge negative for printer rendering. Having a timer-based repaint from an off-screen buffer occur while printing causes the output to change from vector to raster mode, so defeating double-buffering is very important. 2. The next issue is that rendering can be multi-threaded and this can cause problems for the inherently linear print process. The best mode for printing is to render on the GUI thread because this will block other things from interfering with the print process. This causes side effects such as blocking communication with WMS and other server based layers, but this is taken care of in the PrinterDriver by creating a Runnable to run in a separate task, but under control of the PrinterDriver. 3. The next issue is resolution. Normally, of course, we render to screen resolution which is usually between 72 and 120 dots per inch or a pixel size of .~ 28 mm. I do some tricks to increase the apparent resolution without changing the scale. This is especially an issue when there are raster layers. The PrinterPlugin interface has options to double the resolution of raster layers so that even when zooming in on a PDF it still appears smooth. 4. There is the issue of transparency. This is supported in PDF so it isn't a problem there, but it will cause problems for a real printer. The UI has options to defeat transparency and other style settings that might not look quite so nice on a printer. 5. There are also issues of line width scaling that make linestrings almost invisible at printer resolutions. Getting back to more practical advice about implementing PDF generation in OpenJump, I would recommend you start first by implementing the SkyJUMP PrinterDriver and PrinterPlugin. This will allow you to print to PDF with a free PDF print driver without getting into the iText library. You can experiment with commenting out the RenderManager enhancements to see the effects, which for some situations may not be too bad. Once you get the driver working it should be easy add the iText library which gives the direct PDF generation with layers. When testing the PDF output always determine first if it is generating true vectors by zooming in fully. Then you may also see the effects of decimation as implemented in Java2DConverter and even in java.awt.Graphics2D. That's all for now. I've rambled on enough. Let me know what else I can clarify. Regards, Larry On Thu, Mar 14, 2013 at 3:00 AM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi Larry (Becker), I've started pdf printer integration in openjump and the main change that I face is one in RenderingManager where you introduced 3 rendering mode public final static int INTERACTIVE = 0; public final static int SINGLE_THREAD_QUEUE = 1; public final static int EXECUTE_ON_EVENT_THREAD = 2; Before I port this change to OpenJUMP (maybe I'll wait after 1.6 release), I'd like to have a better vision of what problem it is supposed to solve and to know if it is related to the add of printing capabilities. Thanks for all, Michaël -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics
