Hei Sascha and Larry, i really appreciate your conversation (dialog?) because they are done i a way that aims to be clear .. although i don't understand anytime the indeept things, i think i could learn a lot without looking on code
but back to business.. Larry Becker schrieb: > Hi Sascha, > > I agree that the new ThreadQueue is a go. I vote for commit. 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) > 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
