Hi! Larry Becker schrieb: > Thanks Stefan. We appreciate other voices in what was becoming a dialog.
We're talking about a very small technical detail here so nobody who is only concerned in the 'big plot' is willing to follow. My fault. I should talk more about brand new, cool, and hyper-ultra features for the end users ... > I agree with your two problems as stated. > 1 - We cannot determine exactly when a rendering > has ended (successfully or not). > 2 - We have a javax,swing.Timer in RenderingManager > that triggers a repaint any x ms. First of all let me state that we are not talking about 'A new ThreadQueue' any more. The problems we discussing now exist with the old and the new one. See below. My main goal in this thread was to bring on a new ThreadQueue. Are we through with this? If yes, I will commit it. > I'm not sure that changing the repaint timer setting from 1000 to 400 > affects performance significantly. My benchmarks show a 3% increase in > render time for burlulc. I'm not sure if that will be true for all > platforms and CPUs. There could be some advantage from my Dell's P4 > hyper-threading here. I'll have to do more tests on a single CPU to be > sure. I did drop the time to 40 ms and got a 22% increase. At that > level, Jon's comment about too little happening each repaint rang true. Sorry Larry, setting the the value to 400ms does not solve the problem on my lower end machine. The flash is regularly omitted if I zoom to smaller scales. All the tweaking you are suggesting seems to scale with your horse power (only). > A 400 ms repaint timer doesn't solve the problem, but it makes it > bearable for zoom to selected. I can't speak to how this affects the > printing plugins. For databases and WMSLayers, it isn't the solution. Exactly. And you may be supprised: there are people out there who want to print WMS layers too. Ask Jukka! > Are the printing plugins working around this problem now by long delays > or what? The Print/Layout plug-in offers an option to set a wait time for this kind of layers with a comment like "Sorry dear user, we aren't capable to figure out how long it may take to print this layer. Try several value. Do some nested intervals. Do a little trial and error." IMHO this isn't very cool. Same for zooming. To avoid expensive data import into the Print/Layout plug-in we offer the opportunity to insert previews (screen shots) of the map. Later when the real print is done the data needs to be extracted from the GIS. This involves a zooming to a bookmarked position. Zooming is not reliable. So we have the same waiting options here with the same cheesy comment "Sorry, dear user ..." I can live with this. As I said a long time ago at the very beginning of this thread: I can explain this to customers, I'm able proof the quirks and I'm also able to show possible solutions. The real interesting question (to me) is: Is it possible in OpenJUMP to correct little design flaws like this? Even if we have to bend the original design a bit? I'll have a keen look at Landons pluggable renderer stuff ... > I'm trying to assess the impact of not fixing this issue right now. I > don't want to minimize the problem, but I see other more pressing issues > of speed and usability that need my attention right now. I need to work > on the speed of Task Loading, and I found a new issue today working with > very large datasets. It takes a _very_ long time to delete 50,000 > objects. I see big gains with minimal effort expended in these areas. This is fine to me and I appreciate this. I have other things for the 'big plot'(tm) in the pipe too (the improved WMS support e.g). I'm the last who wants to throttle you with unimportant things. :-) > So Sascha, what is your other suggestion for a less radical solution? Larry, the modifications I'd suggested were very easy to implement. I removed the Timer in the RenderingManager, adjusted the Renderers and made the RenderingManager a RenderingMaster which is able to track the rendering. Under [1] you find the according src tree. I left out the docs/libs/dlls and so on. If one is interested look at Renderer, RenderingManager, ImageCachingRenderer, ImageCachingFeatureCollectionRenderer and ZoomToSelectedItemsPlugIn. Now the less radical solution: Start a new thread in ZoomToSelectedItemsPlugIn and let it sleep for 400ms before you do the flash. Something like this has to be done in all cases because the ThreadQueue tells you about the end of a rendering thread and not if the panel is ready for a flash. This has to do with repaint()/copyTo() stuff which has to be done afterwards and takes some (machine dependent) time too. regards, Sascha [1] http://intevation.de/~teichmann/openjump/openjump-src-renderer-mod.tar.bz2 ------------------------------------------------------------------------- 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
