Re: [JPP-Devel] A new ThreadQueue ...

[Sunburned Surveyor]

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!

The Sunburned Surveyor

On 5/24/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> 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 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, or a similar
> > programmer of his experience, agrees that this changes would be
> > beneficial, I say we give Sascha a shot at it. It sounds like she has
> > considered her changes carefully.
> >
> > Just my two cents.
> >
> > The Sunburned Surveyor
> >
> >
> >
> > On 5/24/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> >> 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
> >> which arrives later on the screen but for exporting
> >> the data (to print/layout e.g) it would be nice to have
> >> them arriving one after the other.
> >>
> >> My final goal is to have a simple switch between the normal
> >> and the serial mode. To archive that I try to carefully
> >> refactor the system doing little patches step by step
> >> not to break it. Refactoring the ThreadQueue with it's
> >> 'flaws' seems a to be a good starting point to me.
> >>
> >> One reason for this change is the fact that you are able
> >> to figure out if the default thread runs empty. But there
> >> is no way to figure out when the last thread ends. That
> >> are different things. A mechanism for this is planned.
> >>
> >> Sorry, if I've shadowed my true intentions to much. Maybe
> >> I should discuss more before I send patches.  ;-)
> >>
> >> Back to the technical side:
> >>
> >> The patch needs some testing but I don't expect too much
> >> performance improvement.
> >>
> >> A less intrusive alternative to bind the Runnables that go to the
> >> default ThreadQueue into one thread is to create a container
> >> which self is Runnable (see e.g. RunnableArrayList attached)
> >> and put them into an instance of this class.
> >> This container is put into multiRendererThreadQueue as a Runnable.
> >> With this modification the defaultRendererThreadQueue can
> >> be removed (multiRendererThreadQueue renamed to
> >> defaultRendererThreadQueue). Only an idea ... I'm in discussion
> >> mode now. ;-)
> >>
> >> - Sascha
> >>
> >>
> >> Larry Becker schrieb:
> >>> 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
> >>> really problems, only architectural critiques.  Have you done any
> >>> benchmarks that show that the new SingleThreadQueue speeds up
> >>> rendering?  Your logical argument that it should be more efficient  is
> >>> persuasive,  but  I have been surprised by Java before.
> >>>
> >>> respectfully,
> >>> Larry Becker
> >>>
> >>> On 5/23/07, *Sascha L. Teichmann* <[EMAIL PROTECTED]
> >>> > wrote:
> >>>
> >>> 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 ThreadQueue is some kind of thread serializer.
> >>> e - The DB/WMS ThreadQueue has no public access.
> >>>
> >>> Now I've written a sub class of ThreadQueue: SingleThreadQueue
> >>> (see attachment). This one deals with the issues a, b and d.
> >>> I also attached a patch against RenderingManager [3] to handle e.
> >>>
> >>> The new class (to be placed in package
> >>> com.vividsolutions.jump.workbench.ui.renderer) is a drop-in
> >>> replacement for the default ThreadQueue in RenderingManager.
> >>> Not for the ThreadQueue that handles the DB/WMS layers.
> >>>
> >>> Because Jon l

Re: [JPP-Devel] A new ThreadQueue ...

[Sascha L. Teichmann]

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 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, or a similar
> programmer of his experience, agrees that this changes would be
> beneficial, I say we give Sascha a shot at it. It sounds like she has
> considered her changes carefully.
> 
> Just my two cents.
> 
> The Sunburned Surveyor
> 
> 
> 
> On 5/24/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>> 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
>> which arrives later on the screen but for exporting
>> the data (to print/layout e.g) it would be nice to have
>> them arriving one after the other.
>>
>> My final goal is to have a simple switch between the normal
>> and the serial mode. To archive that I try to carefully
>> refactor the system doing little patches step by step
>> not to break it. Refactoring the ThreadQueue with it's
>> 'flaws' seems a to be a good starting point to me.
>>
>> One reason for this change is the fact that you are able
>> to figure out if the default thread runs empty. But there
>> is no way to figure out when the last thread ends. That
>> are different things. A mechanism for this is planned.
>>
>> Sorry, if I've shadowed my true intentions to much. Maybe
>> I should discuss more before I send patches.  ;-)
>>
>> Back to the technical side:
>>
>> The patch needs some testing but I don't expect too much
>> performance improvement.
>>
>> A less intrusive alternative to bind the Runnables that go to the
>> default ThreadQueue into one thread is to create a container
>> which self is Runnable (see e.g. RunnableArrayList attached)
>> and put them into an instance of this class.
>> This container is put into multiRendererThreadQueue as a Runnable.
>> With this modification the defaultRendererThreadQueue can
>> be removed (multiRendererThreadQueue renamed to
>> defaultRendererThreadQueue). Only an idea ... I'm in discussion
>> mode now. ;-)
>>
>> - Sascha
>>
>>
>> Larry Becker schrieb:
>>> 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
>>> really problems, only architectural critiques.  Have you done any
>>> benchmarks that show that the new SingleThreadQueue speeds up
>>> rendering?  Your logical argument that it should be more efficient  is
>>> persuasive,  but  I have been surprised by Java before.
>>>
>>> respectfully,
>>> Larry Becker
>>>
>>> On 5/23/07, *Sascha L. Teichmann* <[EMAIL PROTECTED]
>>> > wrote:
>>>
>>> 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 ThreadQueue is some kind of thread serializer.
>>> e - The DB/WMS ThreadQueue has no public access.
>>>
>>> Now I've written a sub class of ThreadQueue: SingleThreadQueue
>>> (see attachment). This one deals with the issues a, b and d.
>>> I also attached a patch against RenderingManager [3] to handle e.
>>>
>>> The new class (to be placed in package
>>> com.vividsolutions.jump.workbench.ui.renderer) is a drop-in
>>> replacement for the default ThreadQueue in RenderingManager.
>>> Not for the ThreadQueue that handles the DB/WMS layers.
>>>
>>> Because Jon limited the number of parallel threads in default
>>> queue to 1 I see no reason why to fork a new thread for each
>>> Runnable it processes. Thread creation/shutdown is fairly
>>> expensive. Instead a single background thread is started
>>> which processes the Runnables one by one. If the thread
>>> is idle for 30 secs it shuts itself down. If you have a lot
>>> of (non-WMS/BB) layers this should improve performance
>>> and save some resources. The processing itself is done
>>> with a monitor (synchronized/wait/notify) so there is no
>>> busy wait any more.
>

Re: [JPP-Devel] OpenJUMP is rendering Strings? Very interesting...

[Sunburned Surveyor]

Thank you for that snippet of code Larry. I need to look at it some
more, but I think I understand what is going on. I need to add support
for the built-in renderers for things like the grid and selected
features.

I appreciate the assistance.

The Sunburned Surveyor

On 5/23/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> SS,
>
> public RenderingManager(final LayerViewPanel panel) {
> this.panel = panel;
> repaintTimer.setCoalesce(true);
>
> putAboveLayerables(SelectionBackgroundRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new
> SelectionBackgroundRenderer(panel);
> }
> });
> putAboveLayerables(
> FeatureSelectionRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new
> FeatureSelectionRenderer(panel);
> }
> });
>
> putAboveLayerables(AuditNonDupSelectionRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new
> AuditNonDupSelectionRenderer(panel);
> }
> });
>
> putAboveLayerables(AuditDupSelectionRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new
> AuditDupSelectionRenderer(panel);
> }
> });
>
> putAboveLayerables(LineStringSelectionRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new
> LineStringSelectionRenderer(panel);
> }
> });
>
> putAboveLayerables(PartSelectionRenderer.CONTENT_ID,
> new Renderer.Factory() {
> public Renderer create() {
> return new PartSelectionRenderer(panel);
> }
> });
> }
>
> regards,
> Larry
>
>
> On 5/23/07, Sunburned Surveyor < [EMAIL PROTECTED]> wrote:
> >
> > I was finally able to figure out why I was getting a
> > NullPointerException in my pluggable rendering code. It is becuase
> > OpenJUMP is attempting to render Java String objects. (At least that
> > is what it looks like to me.)
> >
> > My code returns a NullPointerException when it encounters one of these
> > Strings because I didn't design it to return a Renderer objecct for
> > Strings.
> >
> > Here is how I found out what was happening. I added some logging
> > statements using log4j in the LayerViewPanel.repaint() method. I knew
> > that this was the source of the NullPointerException. I also suspected
> > that OpenJUMP was passing me something other that a Layer or WMSLayer
> > to render. So I modified the LayerViewPanel.repaint() method to loop
> > through the List of ContentIDs, or objects to be rendered. I think
> > printed the class name of each object in the List. After I found out
> > that the objects causing me problems were Strings, I modified the
> > logging statements in the repaint() method to also print out the value
> > of the Strings.
> >
> > The Strings that are present in the List of objects to be rendered
> > when OpenJUMP first starts have the following values:
> >
> > SELECTION_BACKGROUND
> > SELECTED_FEATURES
> > SELECTED_LINESTRINGS
> > SELECTED_PARTS
> > GRID
> > SCALE_SHOW
> > SCALE_BAR
> >
> > Isn't this odd? Those Strings almost look like Constant values. I
> > wonder where in the world they are coming from?
> >
> > I've attached a text file that contains the logging statements I put
> > into the modified LayerViewPanel.repaint() method. I have also
> > attached the log file that contains the text from the logging
> > statements.
> >
> > I can modify my pluggable rendering system to ignore String objects,
> > but I'd really like to know how they end up in the ContentIDs List to
> > begin with. Thank you in advance for any suggestions or insight.
> >
> > The Sunburned Surveyor
> >
> > P.S. - I just found a new friend. His name is log4j. :]
> >
> >
> -
> > 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

Re: [JPP-Devel] A new ThreadQueue ...

[Sunburned Surveyor]

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, or a similar
programmer of his experience, agrees that this changes would be
beneficial, I say we give Sascha a shot at it. It sounds like she has
considered her changes carefully.

Just my two cents.

The Sunburned Surveyor



On 5/24/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> 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
> which arrives later on the screen but for exporting
> the data (to print/layout e.g) it would be nice to have
> them arriving one after the other.
>
> My final goal is to have a simple switch between the normal
> and the serial mode. To archive that I try to carefully
> refactor the system doing little patches step by step
> not to break it. Refactoring the ThreadQueue with it's
> 'flaws' seems a to be a good starting point to me.
>
> One reason for this change is the fact that you are able
> to figure out if the default thread runs empty. But there
> is no way to figure out when the last thread ends. That
> are different things. A mechanism for this is planned.
>
> Sorry, if I've shadowed my true intentions to much. Maybe
> I should discuss more before I send patches.  ;-)
>
> Back to the technical side:
>
> The patch needs some testing but I don't expect too much
> performance improvement.
>
> A less intrusive alternative to bind the Runnables that go to the
> default ThreadQueue into one thread is to create a container
> which self is Runnable (see e.g. RunnableArrayList attached)
> and put them into an instance of this class.
> This container is put into multiRendererThreadQueue as a Runnable.
> With this modification the defaultRendererThreadQueue can
> be removed (multiRendererThreadQueue renamed to
> defaultRendererThreadQueue). Only an idea ... I'm in discussion
> mode now. ;-)
>
> - Sascha
>
>
> Larry Becker schrieb:
> > 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
> > really problems, only architectural critiques.  Have you done any
> > benchmarks that show that the new SingleThreadQueue speeds up
> > rendering?  Your logical argument that it should be more efficient  is
> > persuasive,  but  I have been surprised by Java before.
> >
> > respectfully,
> > Larry Becker
> >
> > On 5/23/07, *Sascha L. Teichmann* <[EMAIL PROTECTED]
> > > wrote:
> >
> > 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 ThreadQueue is some kind of thread serializer.
> > e - The DB/WMS ThreadQueue has no public access.
> >
> > Now I've written a sub class of ThreadQueue: SingleThreadQueue
> > (see attachment). This one deals with the issues a, b and d.
> > I also attached a patch against RenderingManager [3] to handle e.
> >
> > The new class (to be placed in package
> > com.vividsolutions.jump.workbench.ui.renderer) is a drop-in
> > replacement for the default ThreadQueue in RenderingManager.
> > Not for the ThreadQueue that handles the DB/WMS layers.
> >
> > Because Jon limited the number of parallel threads in default
> > queue to 1 I see no reason why to fork a new thread for each
> > Runnable it processes. Thread creation/shutdown is fairly
> > expensive. Instead a single background thread is started
> > which processes the Runnables one by one. If the thread
> > is idle for 30 secs it shuts itself down. If you have a lot
> > of (non-WMS/BB) layers this should improve performance
> > and save some resources. The processing itself is done
> > with a monitor (synchronized/wait/notify) so there is no
> > busy wait any more.
> >
> > The DB/WMS ThreadQueue (real parallel threads) is left untouched
> > for the moment. Depending on my personal schedule I will send
> > a patch against this one too. Preliminary code with thread pooling
> > exists but it needs a bit more testing.
> >
> > Find attached the new class and patches against RenderingManager and
> > the

Re: [JPP-Devel] I miss two simple tools

[Stefan Steiniger]

mhm.. reminds me a bit on how cadcorp presents selected features, which 
was very much valued by me. And the area/length feature info is 
something which i also have on my todo list since a year (but put it on 
a lower priority since we have an improved mouse-over-info-tool by Larry).

Cadcorp has 4 tabs on the left (where we have the layer tree) and one 
can switch between the layer view and some other views (e.g. a feature 
info view, a thematic map view).
In dependence of the geometry type it also displays area/length/centroid 
coorddinates/number of vertices.
If the layer is editable then one can also edit the feature values.

like Larry and David I think all this tools are more or less easily 
doable (not speaking of the tab) - but at least I currently have not the 
time in the next weeks to work on something like that.
for now one should at least open a feature request on sourceforge

stefan

Martin Davis schrieb:
> Both excellent ideas, Jukka. I've thought about both of these myself as 
> well...
> 
> I think a nice way to provide #1 would be to enhance the HTML View in 
> the Feature Info window to compute and display the area and length for 
> each feature which is displayed.  This should be an easy enhancement to 
> make.  Would this meet your need?
> 
> Larry's point about the Tooltips may also meet #1 (although is the 
> tooltip always guaranteed to provide this information?  In some cases 
> they may be customized to show something different, right? ).  Anyway, 
> doesn't hurt to have this information provided in more than one place.
> 
> As for #2, I think this is also a very good idea.  We could perhaps use 
> the old MS Access UI as an inspiration.  In it you could display a table 
> in either a grid view (like JUMP does now) or in a "Sheet" view, which 
> displayed one record at a time with the fields laid out vertically.  A 
> navigation control was provided to move between records.  This seems 
> like it would be a nifty thing to have available, in both the Attribute 
> View window and the Feature Info window.  It shouldn't be *too* hard to 
> do - you would have to autogenerate a Swing layout for the fields, but 
> Jon's nifty dialog generation API shows how to do that pretty easily.
> I think the actual geometry should probably not be displayed as part of 
> the fields, but the usual View/Edit button can be provided on the panel. 
> Area & Length could be shown too, as non-editable fields.
> Perhaps some other geometry metadata would be useful as well, such as 
> number of vertices, number of components, number of holes, etc.  (the 
> same info as shown in the Feature Stats layer)
> 
> Larry, I don't see the layout of large numbers of fields as a problem.  
> The panel can simply be allowed to scroll.
> 

-
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

Re: [JPP-Devel] I miss two simple tools

[Martin Davis]

Both excellent ideas, Jukka. I've thought about both of these myself as 
well...

I think a nice way to provide #1 would be to enhance the HTML View in 
the Feature Info window to compute and display the area and length for 
each feature which is displayed.  This should be an easy enhancement to 
make.  Would this meet your need?

Larry's point about the Tooltips may also meet #1 (although is the 
tooltip always guaranteed to provide this information?  In some cases 
they may be customized to show something different, right? ).  Anyway, 
doesn't hurt to have this information provided in more than one place.

As for #2, I think this is also a very good idea.  We could perhaps use 
the old MS Access UI as an inspiration.  In it you could display a table 
in either a grid view (like JUMP does now) or in a "Sheet" view, which 
displayed one record at a time with the fields laid out vertically.  A 
navigation control was provided to move between records.  This seems 
like it would be a nifty thing to have available, in both the Attribute 
View window and the Feature Info window.  It shouldn't be *too* hard to 
do - you would have to autogenerate a Swing layout for the fields, but 
Jon's nifty dialog generation API shows how to do that pretty easily.
I think the actual geometry should probably not be displayed as part of 
the fields, but the usual View/Edit button can be provided on the panel. 
Area & Length could be shown too, as non-editable fields.
Perhaps some other geometry metadata would be useful as well, such as 
number of vertices, number of components, number of holes, etc.  (the 
same info as shown in the Feature Stats layer)

Larry, I don't see the layout of large numbers of fields as a problem.  
The panel can simply be allowed to scroll.

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


-
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

Re: [JPP-Devel] A new ThreadQueue ...

[Sascha L. Teichmann]

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
which arrives later on the screen but for exporting
the data (to print/layout e.g) it would be nice to have
them arriving one after the other.

My final goal is to have a simple switch between the normal
and the serial mode. To archive that I try to carefully
refactor the system doing little patches step by step
not to break it. Refactoring the ThreadQueue with it's
'flaws' seems a to be a good starting point to me.

One reason for this change is the fact that you are able
to figure out if the default thread runs empty. But there
is no way to figure out when the last thread ends. That
are different things. A mechanism for this is planned.

Sorry, if I've shadowed my true intentions to much. Maybe
I should discuss more before I send patches.  ;-)

Back to the technical side:

The patch needs some testing but I don't expect too much
performance improvement.

A less intrusive alternative to bind the Runnables that go to the
default ThreadQueue into one thread is to create a container
which self is Runnable (see e.g. RunnableArrayList attached)
and put them into an instance of this class.
This container is put into multiRendererThreadQueue as a Runnable.
With this modification the defaultRendererThreadQueue can
be removed (multiRendererThreadQueue renamed to
defaultRendererThreadQueue). Only an idea ... I'm in discussion
mode now. ;-)

- Sascha


Larry Becker schrieb:
> 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
> really problems, only architectural critiques.  Have you done any
> benchmarks that show that the new SingleThreadQueue speeds up
> rendering?  Your logical argument that it should be more efficient  is
> persuasive,  but  I have been surprised by Java before.
> 
> respectfully,
> Larry Becker
> 
> On 5/23/07, *Sascha L. Teichmann* <[EMAIL PROTECTED]
> > wrote:
> 
> 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 ThreadQueue is some kind of thread serializer.
> e - The DB/WMS ThreadQueue has no public access.
> 
> Now I've written a sub class of ThreadQueue: SingleThreadQueue
> (see attachment). This one deals with the issues a, b and d.
> I also attached a patch against RenderingManager [3] to handle e.
> 
> The new class (to be placed in package
> com.vividsolutions.jump.workbench.ui.renderer) is a drop-in
> replacement for the default ThreadQueue in RenderingManager.
> Not for the ThreadQueue that handles the DB/WMS layers.
> 
> Because Jon limited the number of parallel threads in default
> queue to 1 I see no reason why to fork a new thread for each
> Runnable it processes. Thread creation/shutdown is fairly
> expensive. Instead a single background thread is started
> which processes the Runnables one by one. If the thread
> is idle for 30 secs it shuts itself down. If you have a lot
> of (non-WMS/BB) layers this should improve performance
> and save some resources. The processing itself is done
> with a monitor (synchronized/wait/notify) so there is no
> busy wait any more.
> 
> The DB/WMS ThreadQueue (real parallel threads) is left untouched
> for the moment. Depending on my personal schedule I will send
> a patch against this one too. Preliminary code with thread pooling
> exists but it needs a bit more testing.
> 
> Find attached the new class and patches against RenderingManager and
> the old ThreadQueue to bring it to work.
> 
> Comments are very welcome. :-)
> 
> Kind regrads,
>   Sascha
> 
> [1] com.vividsolutions.jump.workbench.ui.renderer.ThreadQueue
> [2]
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=4653389E.6000706%40intevation.de
> [3] com.vividsolutions.jump.workbench.ui.renderer.RenderingManager
> 
> Index:
> ./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java
> 
> ===
> RCS file:
> 
> /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java,v
> retrieving revision 1.6
> diff -u - r1.6 RenderingManager.java
> ---
> ./src/c

Re: [JPP-Devel] A new ThreadQueue ...

[Larry Becker]

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 really problems,
only architectural critiques.  Have you done any benchmarks that show that
the new SingleThreadQueue speeds up rendering?  Your logical argument that
it should be more efficient  is persuasive,  but  I have been surprised by
Java before.

respectfully,
Larry Becker

On 5/23/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:


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 ThreadQueue is some kind of thread serializer.
e - The DB/WMS ThreadQueue has no public access.

Now I've written a sub class of ThreadQueue: SingleThreadQueue
(see attachment). This one deals with the issues a, b and d.
I also attached a patch against RenderingManager [3] to handle e.

The new class (to be placed in package
com.vividsolutions.jump.workbench.ui.renderer) is a drop-in
replacement for the default ThreadQueue in RenderingManager.
Not for the ThreadQueue that handles the DB/WMS layers.

Because Jon limited the number of parallel threads in default
queue to 1 I see no reason why to fork a new thread for each
Runnable it processes. Thread creation/shutdown is fairly
expensive. Instead a single background thread is started
which processes the Runnables one by one. If the thread
is idle for 30 secs it shuts itself down. If you have a lot
of (non-WMS/BB) layers this should improve performance
and save some resources. The processing itself is done
with a monitor (synchronized/wait/notify) so there is no
busy wait any more.

The DB/WMS ThreadQueue (real parallel threads) is left untouched
for the moment. Depending on my personal schedule I will send
a patch against this one too. Preliminary code with thread pooling
exists but it needs a bit more testing.

Find attached the new class and patches against RenderingManager and
the old ThreadQueue to bring it to work.

Comments are very welcome. :-)

Kind regrads,
  Sascha

[1] com.vividsolutions.jump.workbench.ui.renderer.ThreadQueue
[2]

http://sourceforge.net/mailarchive/message.php?msg_name=4653389E.6000706%40intevation.de
[3] com.vividsolutions.jump.workbench.ui.renderer.RenderingManager

Index:
./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java,v
retrieving revision 1.6
diff -u -r1.6 RenderingManager.java
---
./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java
22 May 2007 18:47:12 -  1.6
+++
./src/com/vividsolutions/jump/workbench/ui/renderer/RenderingManager.java
24 May 2007 04:10:30 -
@@ -77,7 +77,7 @@
 * non-database layers in parallel. In fact, it will make the GUI
less
 * responsive. [Jon Aquino]
 */
-   private ThreadQueue defaultRendererThreadQueue = new
ThreadQueue(1);
+   private ThreadQueue defaultRendererThreadQueue = new
SingleThreadQueue();

/**
 * WMS and database processing are done on the server side, so
allow these
@@ -294,6 +294,10 @@
return defaultRendererThreadQueue;
}

+   public ThreadQueue getMultiRendererThreadQueue() {
+   return multiRendererThreadQueue;
+   }
+
public void dispose() {
repaintTimer.stop();
defaultRendererThreadQueue.dispose();
@@ -334,4 +338,4 @@
 contentIDToRendererMap.remove(contentID);
 }

-}
\ No newline at end of file
+}

Index:
./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java,v
retrieving revision 1.1
diff -u -r1.1 ThreadQueue.java
---
./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java16
Jun 2005 22:50:38 -  1.1
+++
./src/com/vividsolutions/jump/workbench/ui/renderer/ThreadQueue.java24
May 2007 04:09:15 -
@@ -47,6 +47,10 @@
 private Vector queuedRunnables = new Vector();
 private int maxRunningThreads;

+   public ThreadQueue() {
+   this(1);
+   }
+
 public ThreadQueue(final int maxRunningThreads) {
 this.maxRunningThreads = maxRunningThreads;
 }
@@ -95,7 +99,7 @@
 public static interface Listener {
 public void allRunningThreadsFinished();
 }
-private void fireAllRunningThreadsFinished() {
+

Re: [JPP-Devel] I miss two simple tools

[Larry Becker]

Hi Jukka,

  You always seem to be asking for the same tools as our in-house users.
Whenever I hear the same request from two different sources, I listen.
Rapid access to  length and area information is available when the View->Map
Tooltips option is enabled and you hover the mouse over a feature.

Attribute editing one feature at a time sounds good, but in general it is
not possible to guarantee that a feature's attributes will all fit on one
page.  In some cases you simply trade a horizontal layout for a vertical
one.  Perhaps you could point to an example of another piece of software
that you think does a good job with this problem.

regards,
Larry Becker

On 5/24/07, Rahkonen Jukka <[EMAIL PROTECTED]> wrote:


Hi,

Is there already somewhere in OpenJUMP a tool for getting the perimeter
and area of one selected polygon, or lenght of one selected line?  The
area/lenght calculator in the Analysis is a fine tool, but I need very often
this information for just one feature, and I would like to be able to get it
simply like point-and-shoot.  I believe this is quite a common need for
other users as well.

Another thing I am missing is a user friendly way to edit attributes of
selected features.  Now I can do it by selecting the feature, using Feature
info tool and then editing data on tabular form. However, I think that
tabular form is good for showing attribute info but not so good for
editing.  I would prefer having a bigger sheet for editing attributes, one
page per selected feature.  Does this sound reasonable?

Regards,

-Jukka Rahkonen-


-
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

[JPP-Devel] I miss two simple tools

[Rahkonen Jukka]

Hi,

Is there already somewhere in OpenJUMP a tool for getting the perimeter and 
area of one selected polygon, or lenght of one selected line?  The area/lenght 
calculator in the Analysis is a fine tool, but I need very often this 
information for just one feature, and I would like to be able to get it simply 
like point-and-shoot.  I believe this is quite a common need for other users as 
well.

Another thing I am missing is a user friendly way to edit attributes of 
selected features.  Now I can do it by selecting the feature, using Feature 
info tool and then editing data on tabular form. However, I think that tabular 
form is good for showing attribute info but not so good for editing.  I would 
prefer having a bigger sheet for editing attributes, one page per selected 
feature.  Does this sound reasonable?

Regards,

-Jukka Rahkonen-


-
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