The purpose of this thread is to document a problem with RenderManager and to propose solutions.
The good news: RenderManager is optimized for the most responsive interactive GUI experience. It uses multiple threads, image caching, and timed refresh operations to ensure that the user's perception is that they never have to wait. IMO JUMP is unrivaled in this respect. The bad news: The original JUMP design did not including printing support. Saving a screen image was the only option. Now we have many options supporting printing, SVG, PDF, and image export. This is great, but all of them have to work around RenderManager issues to ensure proper results. Sometimes a long user-specified delay while WMS or server layers finish rendering is necessary. This looks unprofessional and is ultimately unreliable. ---------------------------------------- Here is the preferred solution as I see it (call it the "Interactive Mode Switch" solution): Make a modification to the RenderManager class to include a new property called interactiveMode with associated getters and setters. The interactiveMode property defaults to true. Printing code and other routines that need batch oriented rendering will need to bracket their rendering code with calls to setInteractiveMode(false) and setInteractiveMode(true). In between the calls, rendering operations are guaranteed to be done on the same thread and block until they complete. How this is accomplished: Again, making modifications only to RenderManager, make the following changes: 1. In createRenderer() if interactiveMode is true, it should setMaxFeatures for the Renderer to the maximum integer. This will disable image caching, causing renderers to paint directly to the graphics context. 2. in render() if interactiveMode is true, it should run the Renderer on the event thread instead of using the ThreadQueue. Also it should not start a repaint timer. These changes effectively eliminate any unsynchronized rendering from RenderManager. See the attached copy of RenderManager for details. ----------------------------------------------------- For interactive plug-ins like ZoomToSelectedItems that also need to control rendering order so that the flash operation is synchronized. For ZoomToSelectedItems, in addition to bracketing rendering code with sets, it is also necessary to use invokeLater() on the flash() method so that it will be executed in order with the panel component update. I have tested this solution on both OpenJump and SkyJUMP and it seems to solve the ZoomToSelectedItems flash issue (see attached file for details). I tested on my usual P4 2.4GHz and also on a 1.5GHz Athlon. More testing is needed to determine how well it meets the needs of printing plug-ins. This solution has the advantage that JUMP continues to behave exactly as before until you set the interactiveMode to false. No refactoring of interactive rendering code is necessary. regards, Larry Becker
RenderingManager.java
Description: Binary data
ZoomToSelectedItemsPlugIn.java
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
