Sascha,
I replaced the ThreadQueue.Listener with the following code:
panel.getRenderingManager().getDefaultRendererThreadQueue().add(
new Runnable() {
public void run() {
try {
flash(geometries, panel);
} catch (NoninvertibleTransformException e) {};
}
});
This works great in SkyJUMP where I also used it to fix my refresh timer and
ZoomRealtime, however although it is better than the Listener in OpenJump,
it still occasionally flashes first and then zooms. Clearly there is
something wrong, but it is not in your ThreadQueue code. I'll look some
more tomorrow.
regards,
Larry
On 6/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
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/
--
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
