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
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
