Sascha,
> Don't you have the same effects with the original one?
I begin to see... I can reproduce flash problems easily in JUMP
and OpenJump, but not in SkyJUMP. That explains why we are both
surprised. I have no idea why there is a difference, but I will
investigate further.
regards,
Larry
On 6/18/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Larry,
>
> _exactly_ this the thread lottery we are playing with the
> assumption that no running threads means there no more rendering jobs!
>
> I get the same irritating behavior with the original ThreadQueue.
> I put an System.err.println("flash!") into the listener of
> the zoom plug-in. Sometimes it gets printed before the display
> is in the right 'mood' to display a flash. Result: no visible
> flash or only a shortened variant.
>
> Don't you have the same effects with the original one?
> I have!
>
> Register a println Listener yourself to the ThreadQueue
> and be surprised how often it is called.
>
> The zoom plug-in builds on this assumption the even more venturous
> assumption that the zoom is done when there no more running threads.
> It does not take into account that the hole repaint()/erase()/copyTo()
> stuff also takes some time. The invokeLater() call does not make it
> more predictable.
>
> Let us compare the TQs:
>
> 1) Original TQ:
>
> public void add(final Runnable runnable) {
> queuedRunnables.add(new Runnable() {
> public void run() {
> try {
> runnable.run();
> } finally {
> setRunningThreads(getRunningThreads() - 1);
> processQueue();
> }
> }
> });
> processQueue();
> }
>
> private void setRunningThreads(int runningThreads) {
> this.runningThreads = runningThreads;
> if (runningThreads == 0) { fireAllRunningThreadsFinished(); }
> }
>
> The defaultRenderingThread has only one Thread running.
> -> runningThreads == 1 during try block of new Runnable.run().
>
> setRunningThread() in the finally sets it to zero
> -> listeners get there kick.
>
> This means that after each and every job the listeners get kicked.
>
> 2) New TQ: (in worker thread's run())
>
> for (;;) {
> // unimportant part
> try {
> runnable.run();
> }
> catch (Exception e) {
> e.printStackTrace();
> }
>
> boolean lastRunningThread;
> synchronized (runningThreads) {
> lastRunningThread = runningThreads[0] == 1;
> }
> if (lastRunningThread) {
> fireAllRunningThreadsFinished();
> }
> }
>
> The defaultRenderingThread has only one Thread running.
> -> runningThreads[0] == 1
>
> after the try block lastRunningThread is set to true
> if runningThreads[0] == 1. This is always fulfilled for
> the defaultRenderingThread.
> -> listeners get there kick.
>
> This means that after each and every job the listeners get kicked.
>
> => Same behavior for 1) and 2)
>
> Maybe I bore you a bit by repeating it.
>
> Regards,
> Sascha
>
>
> Larry Becker schrieb:
> > Sascha,
> >
> > Thanks for your patience. I like the idea of preserving the
> > original behavior, however this version doesn't seem to flash
> > consistently. Sometimes it doesn't flash, sometimes it does.
> >
> > regards,
> > Larry
> >
> > On 6/18/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> >> Larry,
> >>
> >> there is probably somebody out there (younger than us)
> >> how says that 400ms feels slow too.
> >>
> >> I've thought a bit about the compromise and came to the
> >> conclusion that we don't need a make a compromise here.
> >>
> >> We have simply to restore the behavior of the
> >> original TheadQueue. The original one fires the
> >> Listeners when the running threads went down to zero.
> >> We can do the same when we're in the situation that we
> >> are the last remaining thread with our job done.
> >>
> >> In this case the number of running threads is
> >> one but this measure wasn't reliable in the old
> >> ThreadQueue too. So it doesn't matter.
> >> But in difference to the original we keep the
> >> worker thread alive afterwards instead of killing it.
> >>
> >> Find attached a new version of the ThreadQueue that
> >> implements this behavior.
> >>
> >> regards,
> >> Sascha
> >>
> >> Larry Becker schrieb:
> >>> Sascha,
> >>>
> >>> I tried one second, and it feels slow. When I am arrowing through a
> >>> selection of records in View/Edit Attributes it makes me wait for the
> >>> flash before I move on. Really, this is becoming an issue of
> >>> compromising the interactivity of the application to achieve some
> >>> theoretical benefit that can't be seen or measured.
> >>>
> >>> How about 400 ms? That is about the average reaction time.
> >>>
> >>> regards,
> >>> Larry Becker
> >> -------------------------------------------------------------------------
> >> 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
>
--
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
