Okay, I've commit it. The new thread Larry started recently will be a better place for the other issue.
Thanks for all your patience! :) Kind regards, Sascha Michaël Michaud schrieb: >> if you both vote for a commit, then commit >> (from my perspective Michael would be the other person for an >> approvement - but probably he is busy - and we both trust you both :o) >> >> > Yes definetely. > I hardly followed your interesting discussion about ThreadQueue but I'm > sure you have good reasons to do this change and I'm grateful if you > could improve this dark part of the code. > > Michaël > >> >> >>> Let's start a new thread that works on rendering changes. I'm open >>> to all solutions, but some of them may take a little longer to >>> incorporate than others. When he is ready, we should evaluate Landon's >>> pluggable rendering system to see if it can be part of the solution. >>> I'm afraid I never really understood what class of problems it was >>> targeted at solving. >>> >>> >> ;) ..an exercise??? >> >> stefan >> >> >>> I'll test the less radical ZoomToSelectedItemsPlugIn solution. We >>> may need to make the RenderManager repaint timer duration get and >>> set-able so that we can synchronize better. >>> >>> I'll also take a look at your proposed rendering system changes, but I >>> would also like to investigate a different solution first. I'll report >>> back soon. >>> >>> regards, >>> Larry >>> >>> On 6/20/07, *Sascha L. Teichmann* <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> 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 >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >>> -- >>> http://amusingprogrammer.blogspot.com/ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> >> >> > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
