>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
