Okay, I've commit it.
The new thread Larry started recently will be a better
place for the other issue.
Thanks for all your patience! :)
Kind regards,
Sascha
Michaël Michaud schrieb:
>> if you both vote for a commit, then commit
>> (from my perspective Michael would be the other person for an
>if you both vote for a commit, then commit
>(from my perspective Michael would be the other person for an
>approvement - but probably he is busy - and we both trust you both :o)
>
>
Yes definetely.
I hardly followed your interesting discussion about ThreadQueue but I'm
sure you have good reas
Hei Sascha and Larry,
i really appreciate your conversation (dialog?) because they are done i
a way that aims to be clear .. although i don't understand anytime the
indeept things, i think i could learn a lot without looking on code
but back to business..
Larry Becker schrieb:
> Hi Sascha,
>
Hi Sascha,
I agree that the new ThreadQueue is a go. I vote for commit.
Let's start a new thread that works on rendering changes. I'm open to
all solutions, but some of them may take a little longer to incorporate than
others. When he is ready, we should evaluate Landon's pluggable render
Hi!
Larry Becker schrieb:
> Thanks Stefan. We appreciate other voices in what was becoming a dialog.
We're talking about a very small technical detail here so
nobody who is only concerned in the 'big plot' is willing
to follow. My fault. I should talk more about brand new, cool,
and hyper-ultra
Thanks Stefan. We appreciate other voices in what was becoming a dialog.
Hi Sascha,
I agree with your two problems as stated.
1 - We cannot determine exactly when a rendering
has ended (successfully or not).
2 - We have a javax,swing.Timer in RenderingManager
except the ones from pirol I am not really aware of other renderers...
but compatibility is (sometimes unfortunately) one of our goals
stefan
Sascha L. Teichmann schrieb:
> Hi Larry,
>
> this all fits together very well and I have
> a couple of comments/ideas. This is most radical one:
>
> Let
Hi Larry,
this all fits together very well and I have
a couple of comments/ideas. This is most radical one:
Let me switch to "software designer mode" for a moment.
(This is what my company is paying me for besides working
with legacy code... ;-)
We have actually two problems:
1 - We cannot dete
Hi Sascha,
I have figured out what is different about rendering timing in SkyJUMP
and OpenJump. The randomly delayed drawing in OpenJump is caused by the
repaintTimer in RenderingManager. In OpenJump and JUMP it is set to 1
second, and in SkyJUMP it is set to 400 ms. This makes SkyJUMP rende
Sascha,
I replaced the ThreadQueue.Listener with the following code:
panel.getRenderingManager().getDefaultRendererThreadQueue().add(
new Runnable() {
public void run() {
try {
flash(geometries, panel);
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,
La
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
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 prob
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 fi
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
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
BTW: It flashes ... after 5 secs.
Solution I: Setting WORKER_STAY_ALIVE_TIME to 1 sec.
That should be a compromise between thread pooling
and user feedback. (i really prefer 5 secs)
Solution II: We can do a test before we
send a worker thread to the idle/stay alive wait.
If it is the last survive
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
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,
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.
>
> rega
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.Lis
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 i
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 leavin
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 co
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 you
Hi Larry,
It would look very suspicious to me if there were no one
who asks critical questions. Ideas have to be discussed.
This brings up aspects or alternative view to front
which potentially were overseen by the originator.
A common and compelling "Yes!" at first glance may lead to
a long or mi
OK Sascha, you win. I see your point. Your logic is inescapable
about the defaultRendering ThreadQueue. My only defense is that my
code will not produce the correct raster without the while (default
queue has running threads) check. WMS Layers (only) will be missing.
Regarding the ArrayIndexOu
Hi Larry,
Larry Becker schrieb:
> Hi Sascha,
>
> Only potentially, but practically speaking my code is blocking the
> GUI thread, and there is nothing running to put more jobs on the
> queue. The while loop in processQueue will keep maxRunningThreads
> running untill the queue begins to empty.
Hi Sascha,
Only potentially, but practically speaking my code is blocking the
GUI thread, and there is nothing running to put more jobs on the
queue. The while loop in processQueue will keep maxRunningThreads
running untill the queue begins to empty. When is empty, there are no
more render job
Hi Larry,
the magic word here is 'critical region'
Have a look a the finally block.
Assume the setRunningThreads(getRunningThreads() - 1) call
was executed and the counter went to zero. This is done in Thread A.
And now directly comes a context switch to your code
in Thread B. Your if statement th
Hi Sascha,
I do not see the difference. It seems to me that when a task is
finished, the runningThreads count is decremented as in:
try {
runnable.run();
} finally {
setRunningThreads(getRunningThreads() - 1);
Hi Larry,
The method is named runningThreads(). This was my
mistake. I will add add get getRunningThreads() to
reestablish compatibility. Thanks for this hint.
BTW: You're code:
while (threadQueue.getRunningThreads() > 0) Thread.sleep(200);
tests if there are running _threads_ left. This do not
It doesn't look like I'm going to have time to test the new
ThreadQueue anytime soon. I did plug it in long enough to determine
that it broke my code that called getRunningThreads() since that
method is no longer present. I didn't have time to look for the new
method that I should use instead.
>Hei Saschachaël
>
>i got positive feedback from my colleaque on the changes of the
>threading stuff.
>If Michael aggrees too, you can commit
>
>
As far as I'm concerned, I am really pleased to see Sascha's
contribution to the core.
OJ really needs contributions from skilled programmers :-) .
Hei Sascha
i got positive feedback from my colleaque on the changes of the
threading stuff.
If Michael aggrees too, you can commit
stefan
Sascha L. Teichmann schrieb:
> Hi!
>
> Stefan Steiniger schrieb:
>> Similar to Landon I have never touched threading nor heared any lectures
>> or read boo
SS,
Sunburned Surveyor schrieb:
> Sascha,
>
> You wrote: "As I pointed out earlier having a ChangeLog would
> be nice to document motivations and backgrounds for a change. Simply
> generating a ChangeLog out of the commit messages is convenient but
> it does not uncover the true potential of such
Sascha,
You wrote: "As I pointed out earlier having a ChangeLog would
be nice to document motivations and backgrounds for a change. Simply
generating a ChangeLog out of the commit messages is convenient but
it does not uncover the true potential of such a 'log' file."
I agree, and I use small tex
Hi!
Stefan Steiniger schrieb:
> Similar to Landon I have never touched threading nor heared any lectures
> or read books on it. Thus .. i dont know if it turns out to be good or bad.
> But i know that making things more clean is good objective. Thus, i
> support the changes. It would be good whe
mhm.. more or less yes/not ;o)
we know that guy (Theodor Förster) who works on that wps services. He
does a thesis at ITC enschede and attends the same workshops as Moritz
because the goals are somehow similar.
but thanx for the link. I need to study it (until know i did only know
two conferen
>[1]: http://www.ixserve.de/pub_whatiswebgen.php (note the links to
>papers dont work but they are available in the following repository:)
>i.e.:
>http://www.geo.unizh.ch/publications/degen/autocarto2005_burghardt_final.pdf
>
>btw. Moritz Neun (my colleague) is currently writing up his thesis. so
finally my 2 cents.
Similar to Landon I have never touched threading nor heared any lectures
or read books on it. Thus .. i dont know if it turns out to be good or bad.
But i know that making things more clean is good objective. Thus, i
support the changes. It would be good when we finally chang
Sascha L. Teichmann a écrit :
>Really back to topic:
>
>Find attached a replacement for ThreadQueue [1].
>To use it just overwrite the original one.
>
>
Hi Sascha :
I think that trying to have a cleaner and more simple code is an
excellent goal, and I'd like to help, but I'm not sure I can und
SS,
no problem ... apologies accepted! :-)
..and I wont tell Jan's wife about it.
Back to topic:
I'am fully aware of possible side effects that I may trigger
with my changing request. It's a bit of a pity that OJ doesn't
have a real devel branch to put in stuff that is a little
'experimental'. T
Sascha,
Please accept my sincerest aopologies. I'm afriad my American
ignorance of other cultures is more than just a little obvious at
times.
I believe I have made the same mistake with Jan. :]
Please be patient with me as I learn the details of cultures across
the Pacific and Atalantic Oceans!
TNX, but for the records 'he' would be more suited in my case.
'Sascha' is basically a Russian term of endearment for the
boys name 'Alexander' but it's also used as a girls name.
BTW: 'Jan' is a girls name in the US too, isn't? ;-)
- Sascha
Sunburned Surveyor schrieb:
> Sascha and Larry,
>
>
Sascha and Larry,
I must admit that I am way over my head here. I haven't done much
thread programming in Java. (Hopefully Stefan has!)
Sascha wrote: "My primary goal is to simplify the
threading code to make it more reliable in terms of time."
This seems like an admirable goal to me. If Larry,
Hi Larry,
short answer first: No, I don't have any benchmarks, yet.
The long answer: My primary goal is to simplify the
threading code to make it more reliable in terms of time.
Gaining performance improvements would be a neat side effect.
Background: Multi-threading may be fine for slow layers
Hi Sascha,
I read your comments and look at your code with interest. It appears to
be an improved ThreadQueue implementation, but will require a lot of testing
to verify. Before I invest this time, I would like to know what problem it
is solving. I see your dislikes a - e, but these are not r
48 matches
Mail list logo
