Take zoom/panning as an example:
When I zoom to a certain level I often do some zooming
or panning within a few seconds again because the
viewport is not adjust the way I really want it to be.
I agree with you in principle and therefore the 'pooling' of
threads in the new ThreadQueue is only light version:
just keeping a running thread a little alive.
For say one second instead of five?!
- Sascha
Larry Becker schrieb:
> Thread pooling may be important for servers, but it doesn't seem to be
> a performance factor in JUMP. If no new jobs are being added in 50
> ms, the cpu is probably idle anyway.
>
> regards,
> Larry
>
> On 6/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>> Not if you want to do thread pooling.
>>
>> The real problem: How can I get a notification
>> when a zoom is done?
>>
>> The ZoomToSelectedItemsPlugIn ThreadQueue code looks
>> like a workaround due to lack of a real possibility
>> to get informed when the zoom is done.
>>
>> I will have a look at this problem.
>>
>> regards,
>> Sascha
>>
>>
>> Larry Becker schrieb:
>>> I cut the WORKER_STAY_ALIVE_TIME to 50 ms and the flash now works. 50
>>> ms is an eternity in CPU time anyway.
>>>
>>> regards,
>>> Larry
>>>
>>> On 6/15/07, Larry Becker <[EMAIL PROTECTED]> wrote:
>>>> Thanks for finding that Listener use in ZoomToSelectedItemsPlugIn. I
>>>> tried it and it doesn't flash anymore.
>>>>
>>>> regards,
>>>> Larry
>>>>
>>>> On 6/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>>>> In core the
>>>>>
>>>>> com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn
>>>>>
>>>>> uses the ThreadQueue.Listener interface. But the code looks like it can
>>>>> cope with the 'slightly' shifted semantic.
>>>>>
>>>>> I would vote for stick a @deprecated tag (+ some explanations)
>>>>> to the respective methods and to the interface because code
>>>>> that uses these mechanisms is possibly not aware of the
>>>>> sophisticated difference between 'no running threads left'
>>>>> and 'all jobs done'.
>>>>>
>>>>> - Sascha
>>>>>
>>>>>
>>>>> Larry Becker schrieb:
>>>>>> Hi Sascha,
>>>>>>
>>>>>> Adding a 'wakeup' Runnable works great and is easier than using the
>>>>>> listener anyway.
>>>>>>
>>>>>> By the way, I couldn't find any other code using the Listener
>>>>>> interface, but I suppose there could be a Plug-in somewhere that does.
>>>>>> We should probably leave it out anyway since if we are leaving it in
>>>>>> for compatibility, it should actually be compatible. The easiest way
>>>>>> to find out if it is really needed by anyone but me might be to leave
>>>>>> it out and see if it breaks anyone's compile. The same applies to
>>>>>> getRunningThreads since it doesn't behave exactly like it did before
>>>>>> either.
>>>>>>
>>>>>> Anyway, thanks for the help. I'm able to determine the end of
>>>>>> rendering much more accurately now.
>>>>>>
>>>>>> regards,
>>>>>> Larry Becker
>>>>>>
>>>>>> On 6/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>>>>>> Hello Larry,
>>>>>>>
>>>>>>> the version of the ThreadQueue is a bit outdated.
>>>>>>> The version you have has no getRunningThreads() method.
>>>>>>> This is need for compatibility. And there was a bug in
>>>>>>> remove(Listener) which is fixed by now.
>>>>>>> I attach the current ThreadQueue.
>>>>>>>
>>>>>>> Now to your problem:
>>>>>>>
>>>>>>> The Listeners are in for compatibility and you are right
>>>>>>> they get there kick when the WORKER_STAY_ALIVE_TIME has
>>>>>>> expired. But once again: These Listeners _do_ _not_ help
>>>>>>> you! You want to know when the last job has ended, not
>>>>>>> when there are no more running Threads. We discussed this
>>>>>>> already.
>>>>>>>
>>>>>>> I would suggest the following solution on your side
>>>>>>> to archive the desired effect:
>>>>>>>
>>>>>>> <code>
>>>>>>>
>>>>>>> Graphics2D destination = ... // from outer space
>>>>>>>
>>>>>>> LayerViewPanel layerViewPanel = ... // from outer space
>>>>>>>
>>>>>>> RenderingManager renderingManager =
>>>>>>> layerViewPanel.getRenderingManager();
>>>>>>>
>>>>>>> ThreadQueue defaultThreadQueue =
>>>>>>> renderingManager.getDefaultRendererThreadQueue();
>>>>>>>
>>>>>>> // add all the Renderer Runnables to the ThreadQueue
>>>>>>> renderingManager.renderAll();
>>>>>>>
>>>>>>> final boolean [] locked = { true };
>>>>>>>
>>>>>>> // because defaultThreadQueue does its jobs
>>>>>>> // one after each other append a 'wakeup' Runnable ...
>>>>>>>
>>>>>>> defaultThreadQueue.add(new Runnable() {
>>>>>>> public void run() {
>>>>>>> synchronized (locked) {
>>>>>>> locked[0] = false;
>>>>>>> locked.notify();
>>>>>>> }
>>>>>>> }
>>>>>>> });
>>>>>>>
>>>>>>> try {
>>>>>>> synchronized (locked) {
>>>>>>> // you could simply write
>>>>>>> // "while (locked[0]) locked.wait();"
>>>>>>> // but following is more defensive
>>>>>>> int count = 0;
>>>>>>> while (locked[0] && count++ < 10)
>>>>>>> locked.wait(10000L);
>>>>>>> }
>>>>>>> }
>>>>>>> catch (InterruptedException ie) {
>>>>>>> }
>>>>>>>
>>>>>>> renderingManager.copyTo(destination);
>>>>>>>
>>>>>>> </code>
>>>>>>>
>>>>>>> But as I said earlier, this only works on
>>>>>>> the defaultRenderingThreadQueue and therefore
>>>>>>> its only an interim solution. The
>>>>>>> WMS/DB ThreadQueue is private and a true
>>>>>>> parallel ThreadQueue.
>>>>>>>
>>>>>>> My goal is to add a renderAllSynchronized()
>>>>>>> to RenderingManager that used the above
>>>>>>> Runnable/unlock trick. The secret WMS/DB
>>>>>>> will be eliminated (or better the default one
>>>>>>> and the WMS/DB ThreadQueue will become the
>>>>>>> default). This is doable with the
>>>>>>> RunnableArrayList class I posted a while
>>>>>>> ago, which simulates the single thread
>>>>>>> default ThreadQueue. But one step after
>>>>>>> the other ...
>>>>>>>
>>>>>>> Regards, Sascha
>>>>>>>
>>>>>>>
>>>>>>> Larry Becker schrieb:
>>>>>>>> Sascha,
>>>>>>>>
>>>>>>>> I have reached a point where I need some help with the new
>>>>>>>> ThreadQueue implementation. I have modified my code that calls
>>>>>>>> getRunningThreads to use the Listener with the
>>>>>>>> allRunningThreadsFinished method instead. This was much cleaner and
>>>>>>>> worked fine until I replaced ThreadQueue with your version. The
>>>>>>>> problem I seem to be having is that the method doesn't fire until
>>>>>>>> after the 5 second WORKER_STAY_ALIVE_TIME has expired. Can you
>>>>>>>> explain what I should be doing or modify the code so that it fires
>>>>>>>> when there are no more jobs waiting?
>>>>>>>>
>>>>>>>> I have attached the version of ThreadQueue.java that I have been using
>>>>>>>> in case it is outdated.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> 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
>>
>
>
-------------------------------------------------------------------------
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
