Hi Sascha, Thanks for taking time to look at the proposed changes. They still need more tweaking and testing, but I didn't want to go too long without getting comments.
> - Why don't you set the rendering mode back to interactive in the > flash Runnable? Oops, I accidentally attached a different version than I had thought. In my current version of ZoomToSelectedPlugIn, I leave the RenderingManager in Interactive mode. After much testing with slow database layers, I have come to the opinion that synchronizing the flash is not as important as the ability to arrow to the next feature without waiting (using the View/Edit Attributes panel). I'm not against trying other things, but I have been testing a lot of different options for days and have found that it is all a compromise between latency and consistency. I didn't want to get hung up on ZoomToSelectedPlugIn since it is not the reason for the mod. > - Why it is still necessary to have a GUI blocking mode? I just found it to be more convenient to use in my LayerPrinter2 code than doing the wait loop for the synchronized lock flag. >This solution would be nearly identical with my plan to add >pure single threaded mode to RenderingManager some months ago >so this would be fine with me. I'm too lazy now to search the >mail archive, but I can do so if you want me to do. Yes, I did go back and review everything that you said on the subject and tried to incorporate the intent of your single threaded mode. I have great hopes for this mode, but I don't have any code yet that can test it and benefit from it. The reason it was in the attached ZoomToSelectedPlugIn was just to test that it was working. Hopefully, you can make this mode into exactly what you need to support printing. The important thing for me is that we have a way to set the rendering mode that preserves the advantages of the current system, while supporting new rendering modes for different purposes. regards, Larry Becker On 6/27/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > Hi Larry, > > I'm still very busy, but two remarks and two questions: > > - Add 'final' modifier to the new constants in RenderingManager, please. > (After the second question you may come to the insight that these > constants are not really needed at all.) > > - The flash Runnable in ZoomToSelectedPlugIn doesn't flash on my > computer all the time. This has to do with the latency between the > finish of the last renderer and the copyTo() stuff. I suggested once > (the not so radical method, remember?) that you should start a new > thread in that Runnable, let it sleep for say 400ms and do flash > afterwards to compensate this. But the best value depends on the > particular machine. > > - Why don't you set the rendering mode back to interactive in the > flash Runnable? > > - Why it is still necessary to have a GUI blocking mode? > > You can use the notifyWhenDone Runnable in > SINGLE_THREAD_QUEUE mode as a wakeup Runnable. Then there > would be only modes left: Interactive and the single thread version. > In this case notifyWhenDone can double a an indicator if > the interactive mode is on (notifyWhenDone != null) or off ( == null). > > This solution would be nearly identical with my plan to add > pure single threaded mode to RenderingManager some months ago > so this would be fine with me. I'm too lazy now to search the > mail archive, but I can do so if you want me to do. > > BTW: I'd found some problems with the last solution you > had proposed but with now having a single threaded mode > (as I hoped for so long) these problems have vanished. > > Regard, > Sascha > > Larry Becker schrieb: > > I have completed the RenderingManager modifications. It now supports > > three modes of interactivity: interactive, single thread queue, or > > execute on event thread. It defaults to interactive which operates > > just as it always did. > > > > The execute on event thread mode blocks the GUI, and the single thread > > queue renders all layers sequentially on the default renderer thread > > queue. > > > > I have also added the capability to request a call back in the form of > > a Runnable when rendering is complete. The definition of complete > > varies with the mode of interactivity. > > > > I have tested the new code in interactive mode with the > > ZoomToSelectedItemsPlugIn, and in execute on event thread mode on my > > LayerPrinter2 plug-in which generates high resolution images. > > Everything seems to be working fine. I hope that others can get some > > time to test the modifications. > > > > regards, > > Larry Becker > > > > On 6/26/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >> Sascha, > >> > >> Thanks for checking it out. No rush. > >> > >> > I'm still a bit concerned that the hole expensive rendering is done > >> >inside the event dispatch thread. I have to test if this may lead to > >> >trouble elsewhere. > >> > >> I also got a little concerned about the effect of GUI blocking on > >> ZoomToSelectedItemsPlugIn so I tested some really slow server layers. > >> It took about 30 seconds for the zoom and flash to occur. Clearly, > >> this is a case of the cure being worse than the disease. Flashing out > >> of order or not flashing at all seems pretty trivial when you are > >> waiting for something to happen. Since the GUI is frozen, the user > >> could panic and kill the application. > >> > >> It would seem that my solution need some more tweaking. > >> > >> I'll post again after I've made some modifications to change to a > >> non-blocking notifying version. > >> > >> regards, > >> Larry Becker > >> > >> On 6/25/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > >> > Larry, > >> > > >> > Larry Becker schrieb: > >> > > [...] > >> > > I'm hoping someone will verify that this solution works for printing > >> > > plugins. > >> > > >> > I will implement a path for the Print/Layout plug-in to be able > >> > to test it. I'm quiet a bit busy at the moment so results will only > >> > be available in two days. > >> > > >> > > [...] > >> > > >> > Regards, > >> > Sascha > >> > > >> > > > ------------------------------------------------------------------------- > 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 > -- 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
