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
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
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,
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 reasons
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 me
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
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
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
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
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
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
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
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,
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,
Sascha,
I replaced the ThreadQueue.Listener with the following code:
panel.getRenderingManager().getDefaultRendererThreadQueue().add(
new Runnable() {
public void run() {
try {
flash(geometries, panel);
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
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
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
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
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,
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,
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
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.
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
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.
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 a
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
[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
by
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
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'.
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
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
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,
I
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
Hi together,
as some of you may already know i have my dislikes against
ThreadQueue [1] (Hi, Larry!) see my mail [2]
a - It forks a new thread for any Runnable it processes.
b - It has an ugly busy wait loop inside.
c - The event listener for empty queue fires to often.
d - The default
35 matches
Mail list logo
