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
