Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Larry Becker 

Hi Stefan,

 I intended to say that we should replace the memory label with the new
memory graph.  That will prevent the "misleading" Committed Memory display
from confusing everyone.

regards,
Larry

On 3/26/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:


yes.. a good opinion :)

but where to put the graph?

stefan

Larry Becker schrieb:
> Hi Erwan,
>
> Here is my answer again.  I cut out all of the prior post history so it
> should make it though.
>
>   I have found that many things in OJ use a lot of temporary memory, but
> don't trigger the garbage collection so the Committed Memory label often
> gives a pessimistic view.  There is a one second timer in
> com.vividsolutions.jump
> .workbench.ui.WorkbenchFrame that updates the Committed Memory display
> constantly.
>
>   To fix this issue, we would need to use System.gc(), however it would
> not be advisable to do this inside the timer event that updates the
> Committed Memory label because it might slow down any threads that are
> running.  Ideally, you would do it when OJ is idle, something I have
> found extremely difficult to determine.
>
>   Here is an alternative solution.  The Committed Memory label could be
> converted to a more dynamic indicator by generating a color coded bar
> graph (green, yellow, red) as the remaining free memory decreases. This
> allows the user to focus on the most important thing about memory usage:
> when free memory is low, OJ slows down due to frequent garbage
collections.
>
>  If you wanted to know exact figures, you could always use the Info tab
> on the Help->About box.  The About method gives a much more accurate
> static picture of memory usage since it includes a garbage collect
button.
>
> Does anyone have an opinion on this possible change?
>
> regards,
> Larry Becker
>
>
> 
>
>
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel





--
http://amusingprogrammer.blogspot.com/
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Stefan Steiniger 
just raise the limit.

if things are sended in html or something, there may be a lots of overhead

stefan

Sunburned Surveyor schrieb:
> Larry and other developers,
>  
> Please don't give up on our list! I did get a prompt from SourceForge 
> asking me to approve the message because it exceeded the size limit. I 
> don't understand why this is, as the message had no attachment. I also 
> saw no attachments in earlier messages on this thread.
>  
> Does anyone know what might be going on with the mailing list. I can 
> always submit a support request to try and figure this out. I'm open to 
> suggestions on how to resolve this problem.
>  
> Landon
> 
>  
> On 3/26/07, *Larry Becker* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> Hi Pedro,
> 
>   The list got the first copy of the message you sent.  Are you
> getting bounce messages for replies to this thread like I am? 
> Apparently the size went over 40K or something.  I sent an answer to
> R1, but I got bounce messages so I'm not sure if it was sent.  I'm
> about ready to give up on the JPP list.
> 
>   Anyway, thanks for the info!  I have been meaning to get into
> performance tuning, but it appears that you have achieved some
> success already.  Can you tell me what aspects of OJ were affected
> by your performance tuning and do you have any specific figures on
> improvements?
> 
> regards,
> Larry Becker
> 
> On 3/25/07, *Pedro Doria Meunier* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> Hi guys
> 
>  
> 
> This is what I use in my command line with really improved
> performance:
> 
>  
> 
> start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m
> -XX:NewSize=24m -XX:SurvivorRatio=128
> 
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0
> 
> -XX:CMSInitiatingOccupancyFraction=60
> 
> -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel
> 
> -Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp
> %CLASSPATH%
> 
> com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en
> -properties
> 
> workbench-properties.xml -plug-in-directory %LIB%/ext
> 
>  
> 
> Note the -XX:ParallelGCThreads=2 switch… everyone with an
> hyperthreading or dual-core processor should use this… ;-)
> 
> There's also some trickery around the garbage collector policies.
> 
>  
> 
> Best regards,
> 
> Pedro.
> 
>  
> 
> *From:* [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
> [mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>] *On
> Behalf Of *erwan bocher
> *Sent:* domingo, 25 de Março de 2007 10:57
> *To:* List for discussion of JPP development and use.
> *Subject:* Re: [JPP-Devel] speed up of rendering
> 
>  
> 
> Hi,
> 
> One remark about memory consumed  in OJ. When I load a shapefile
> with 36 580 polygons (size 18 mb) the memory using by my java
> virtual is up to 202 mb. If I minimize my OpenJUMP windows and I
> open it again the JVM display : 85 mb.
> 
> R1.
> 
> 
> On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> you are right.. if i click on the zoombar.. then everything
> seems to be
> faster(=normal) with my modified version.
> 
> I actually see the slow behaviour too if i move the slider with
> an older
> jump version and a jump-i18n version (which is a bit odd, since the
> other version i did test for comparing was a newer openjump-cvs
> version
> from august last year.. so somebody did something change in between)
> 
> Btw.. there is no need to fix that now.. weekends should be
> weekends ;)
> 
> stefan
> 
> Larry Becker schrieb:
> >  Hi Stefan,
> >
> >I seem to be duplicating the Zoom bar behavior you reported
> without
> >  the speed mod.  If I click and drag the zoom bar slider, I get
> very slow
> >  redraw times on the order of ten seconds, however If I click
> the zoom
> >  bar it is faster.  I think JUMP is starting multiple render
> threads
> >  while the zoom bar slider is being dragged.  This co

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Stefan Steiniger 
yes.. a good opinion :)

but where to put the graph?

stefan

Larry Becker schrieb:
> Hi Erwan,
> 
> Here is my answer again.  I cut out all of the prior post history so it 
> should make it though.
> 
>   I have found that many things in OJ use a lot of temporary memory, but 
> don't trigger the garbage collection so the Committed Memory label often 
> gives a pessimistic view.  There is a one second timer in 
> com.vividsolutions.jump
> .workbench.ui.WorkbenchFrame that updates the Committed Memory display 
> constantly.
> 
>   To fix this issue, we would need to use System.gc(), however it would 
> not be advisable to do this inside the timer event that updates the 
> Committed Memory label because it might slow down any threads that are 
> running.  Ideally, you would do it when OJ is idle, something I have 
> found extremely difficult to determine.
> 
>   Here is an alternative solution.  The Committed Memory label could be 
> converted to a more dynamic indicator by generating a color coded bar 
> graph (green, yellow, red) as the remaining free memory decreases. This 
> allows the user to focus on the most important thing about memory usage: 
> when free memory is low, OJ slows down due to frequent garbage collections.
> 
>  If you wanted to know exact figures, you could always use the Info tab 
> on the Help->About box.  The About method gives a much more accurate 
> static picture of memory usage since it includes a garbage collect button. 
> 
> Does anyone have an opinion on this possible change?
> 
> regards,
> Larry Becker
> 
> 
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> 
> 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Larry Becker 

Hi Erwan,

Here is my answer again.  I cut out all of the prior post history so it
should make it though.

 I have found that many things in OJ use a lot of temporary memory, but
don't trigger the garbage collection so the Committed Memory label often
gives a pessimistic view.  There is a one second timer in
com.vividsolutions.jump.workbench.ui.WorkbenchFrame that updates the
Committed Memory display constantly.

 To fix this issue, we would need to use System.gc(), however it would not
be advisable to do this inside the timer event that updates the Committed
Memory label because it might slow down any threads that are running.
Ideally, you would do it when OJ is idle, something I have found extremely
difficult to determine.

 Here is an alternative solution.  The Committed Memory label could be
converted to a more dynamic indicator by generating a color coded bar graph
(green, yellow, red) as the remaining free memory decreases. This allows the
user to focus on the most important thing about memory usage: when free
memory is low, OJ slows down due to frequent garbage collections.

If you wanted to know exact figures, you could always use the Info tab on
the Help->About box.  The About method gives a much more accurate static
picture of memory usage since it includes a garbage collect button.

Does anyone have an opinion on this possible change?

regards,
Larry Becker
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Sunburned Surveyor 

Larry and other developers,

Please don't give up on our list! I did get a prompt from SourceForge asking
me to approve the message because it exceeded the size limit. I don't
understand why this is, as the message had no attachment. I also saw no
attachments in earlier messages on this thread.

Does anyone know what might be going on with the mailing list. I can always
submit a support request to try and figure this out. I'm open to suggestions
on how to resolve this problem.

Landon


On 3/26/07, Larry Becker <[EMAIL PROTECTED]> wrote:


Hi Pedro,

  The list got the first copy of the message you sent.  Are you getting
bounce messages for replies to this thread like I am?  Apparently the size
went over 40K or something.  I sent an answer to R1, but I got bounce
messages so I'm not sure if it was sent.  I'm about ready to give up on the
JPP list.

  Anyway, thanks for the info!  I have been meaning to get into
performance tuning, but it appears that you have achieved some success
already.  Can you tell me what aspects of OJ were affected by your
performance tuning and do you have any specific figures on improvements?

regards,
Larry Becker

 On 3/25/07, Pedro Doria Meunier <[EMAIL PROTECTED]> wrote:

>   Hi guys
>
>
>
> This is what I use in my command line with really improved performance:
>
>
>
> start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m -XX:NewSize=24m
> -XX:SurvivorRatio=128
>
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0
>
> -XX:CMSInitiatingOccupancyFraction=60
>
> -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel
>
> -Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp
> %CLASSPATH%
>
> com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en -properties
>
> workbench-properties.xml -plug-in-directory %LIB%/ext
>
>
>
> Note the -XX:ParallelGCThreads=2 switch… everyone with an hyperthreading
> or dual-core processor should use this… ;-)
>
> There's also some trickery around the garbage collector policies.
>
>
>
> Best regards,
>
> Pedro.
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *erwan
> bocher
> *Sent:* domingo, 25 de Março de 2007 10:57
> *To:* List for discussion of JPP development and use.
> *Subject:* Re: [JPP-Devel] speed up of rendering
>
>
>
> Hi,
>
> One remark about memory consumed  in OJ. When I load a shapefile with 36
> 580 polygons (size 18 mb) the memory using by my java virtual is up to 202
> mb. If I minimize my OpenJUMP windows and I open it again the JVM display :
> 85 mb.
>
> R1.
>
>
>  On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]> wrote:
>
> you are right.. if i click on the zoombar.. then everything seems to be
> faster(=normal) with my modified version.
>
> I actually see the slow behaviour too if i move the slider with an older
> jump version and a jump-i18n version (which is a bit odd, since the
> other version i did test for comparing was a newer openjump-cvs version
> from august last year.. so somebody did something change in between)
>
> Btw.. there is no need to fix that now.. weekends should be weekends ;)
>
> stefan
>
> Larry Becker schrieb:
> > Hi Stefan,
> >
> >I seem to be duplicating the Zoom bar behavior you reported without
> > the speed mod.  If I click and drag the zoom bar slider, I get very
> slow
> > redraw times on the order of ten seconds, however If I click the zoom
> > bar it is faster.  I think JUMP is starting multiple render threads
> > while the zoom bar slider is being dragged.  This could explain the
> slow
> > behavior.  Also the very large polygons that you are testing with
> don't
> > seem to be simplified by the ZoomBar's randomGeometries() unless the
> > number of geometries is greater than 100.
> >
> > Can you test it again and see if the large slowdown only occurs when
> you
> > drag the zoom bar (in any version of JUMP).
> >
> > thanks,
> > Larry
> >
> > On 3/24/07, * Larry Becker* < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Hi Stefan,
> >
> >   It occurs to me that I never use the Zoom bar so I probably
> > haven't tested it.   The Zoom bar does a more radical kind of
> > decimation simplification itself.  It might be interacting with
> the
> > Java2DConverter decimation in a bad way.  I'll check it out.
> >
> > thanks,
> > Larry
> >
> >
> >
> >
> > On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> > > wrote:
> >
> > Hei Larry,
&

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread erwan bocher 

Hi Larry,

I haven't received your answer :-(.

Pedro,

Thanks to the proposition. It works on my laptop but as saids Larry "Can you
tell me what aspects of OJ were affected by your performance tuning and do
you have any specific figures on improvements? "

Kenavo

R1.


On 3/26/07, Larry Becker <[EMAIL PROTECTED]> wrote:


Hi Pedro,

  The list got the first copy of the message you sent.  Are you getting
bounce messages for replies to this thread like I am?  Apparently the size
went over 40K or something.  I sent an answer to R1, but I got bounce
messages so I'm not sure if it was sent.  I'm about ready to give up on the
JPP list.

  Anyway, thanks for the info!  I have been meaning to get into
performance tuning, but it appears that you have achieved some success
already.  Can you tell me what aspects of OJ were affected by your
performance tuning and do you have any specific figures on improvements?

regards,
Larry Becker

On 3/25/07, Pedro Doria Meunier <[EMAIL PROTECTED]> wrote:

>  Hi guys
>
>
>
> This is what I use in my command line with really improved performance:
>
>
>
> start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m -XX:NewSize=24m
> -XX:SurvivorRatio=128
>
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0
>
> -XX:CMSInitiatingOccupancyFraction=60
>
> -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel
>
> -Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp
> %CLASSPATH%
>
> com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en -properties
>
> workbench-properties.xml -plug-in-directory %LIB%/ext
>
>
>
> Note the -XX:ParallelGCThreads=2 switch… everyone with an hyperthreading
> or dual-core processor should use this… ;-)
>
> There's also some trickery around the garbage collector policies.
>
>
>
> Best regards,
>
> Pedro.
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *erwan
> bocher
> *Sent:* domingo, 25 de Março de 2007 10:57
> *To:* List for discussion of JPP development and use.
> *Subject:* Re: [JPP-Devel] speed up of rendering
>
>
>
> Hi,
>
> One remark about memory consumed  in OJ. When I load a shapefile with 36
> 580 polygons (size 18 mb) the memory using by my java virtual is up to 202
> mb. If I minimize my OpenJUMP windows and I open it again the JVM display :
> 85 mb.
>
> R1.
>
>
>  On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]> wrote:
>
> you are right.. if i click on the zoombar.. then everything seems to be
> faster(=normal) with my modified version.
>
> I actually see the slow behaviour too if i move the slider with an older
> jump version and a jump-i18n version (which is a bit odd, since the
> other version i did test for comparing was a newer openjump-cvs version
> from august last year.. so somebody did something change in between)
>
> Btw.. there is no need to fix that now.. weekends should be weekends ;)
>
> stefan
>
> Larry Becker schrieb:
> > Hi Stefan,
> >
> >I seem to be duplicating the Zoom bar behavior you reported without
> > the speed mod.  If I click and drag the zoom bar slider, I get very
> slow
> > redraw times on the order of ten seconds, however If I click the zoom
> > bar it is faster.  I think JUMP is starting multiple render threads
> > while the zoom bar slider is being dragged.  This could explain the
> slow
> > behavior.  Also the very large polygons that you are testing with
> don't
> > seem to be simplified by the ZoomBar's randomGeometries() unless the
> > number of geometries is greater than 100.
> >
> > Can you test it again and see if the large slowdown only occurs when
> you
> > drag the zoom bar (in any version of JUMP).
> >
> > thanks,
> > Larry
> >
> > On 3/24/07, * Larry Becker* < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Hi Stefan,
> >
> >   It occurs to me that I never use the Zoom bar so I probably
> > haven't tested it.   The Zoom bar does a more radical kind of
> > decimation simplification itself.  It might be interacting with
> the
> > Java2DConverter decimation in a bad way.  I'll check it out.
> >
> > thanks,
> > Larry
> >
> >
> >
> >
> > On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> > > wrote:
> >
> > Hei Larry,
> >
> > Larry Becker schrieb:
> > >  Hi Stefan,
> > >
> > >  1.  Is there somewhere I can get a copy of the shape file
> to
> > te

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Larry Becker 

Hi Pedro,

 The list got the first copy of the message you sent.  Are you getting
bounce messages for replies to this thread like I am?  Apparently the size
went over 40K or something.  I sent an answer to R1, but I got bounce
messages so I'm not sure if it was sent.  I'm about ready to give up on the
JPP list.

 Anyway, thanks for the info!  I have been meaning to get into performance
tuning, but it appears that you have achieved some success already.  Can you
tell me what aspects of OJ were affected by your performance tuning and do
you have any specific figures on improvements?

regards,
Larry Becker

On 3/25/07, Pedro Doria Meunier <[EMAIL PROTECTED]> wrote:


 Hi guys



This is what I use in my command line with really improved performance:



start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m -XX:NewSize=24m
-XX:SurvivorRatio=128

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0

-XX:CMSInitiatingOccupancyFraction=60

-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel

-Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp %CLASSPATH%


com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en -properties

workbench-properties.xml -plug-in-directory %LIB%/ext



Note the -XX:ParallelGCThreads=2 switch… everyone with an hyperthreading
or dual-core processor should use this… ;-)

There's also some trickery around the garbage collector policies.



Best regards,

Pedro.



*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *erwan
bocher
*Sent:* domingo, 25 de Março de 2007 10:57
*To:* List for discussion of JPP development and use.
*Subject:* Re: [JPP-Devel] speed up of rendering



Hi,

One remark about memory consumed  in OJ. When I load a shapefile with 36
580 polygons (size 18 mb) the memory using by my java virtual is up to 202
mb. If I minimize my OpenJUMP windows and I open it again the JVM display :
85 mb.

R1.


 On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]> wrote:

you are right.. if i click on the zoombar.. then everything seems to be
faster(=normal) with my modified version.

I actually see the slow behaviour too if i move the slider with an older
jump version and a jump-i18n version (which is a bit odd, since the
other version i did test for comparing was a newer openjump-cvs version
from august last year.. so somebody did something change in between)

Btw.. there is no need to fix that now.. weekends should be weekends ;)

stefan

Larry Becker schrieb:
> Hi Stefan,
>
>I seem to be duplicating the Zoom bar behavior you reported without
> the speed mod.  If I click and drag the zoom bar slider, I get very slow

> redraw times on the order of ten seconds, however If I click the zoom
> bar it is faster.  I think JUMP is starting multiple render threads
> while the zoom bar slider is being dragged.  This could explain the slow

> behavior.  Also the very large polygons that you are testing with don't
> seem to be simplified by the ZoomBar's randomGeometries() unless the
> number of geometries is greater than 100.
>
> Can you test it again and see if the large slowdown only occurs when you
> drag the zoom bar (in any version of JUMP).
>
> thanks,
> Larry
>
> On 3/24/07, * Larry Becker* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi Stefan,
>
>   It occurs to me that I never use the Zoom bar so I probably
> haven't tested it.   The Zoom bar does a more radical kind of
> decimation simplification itself.  It might be interacting with the
> Java2DConverter decimation in a bad way.  I'll check it out.
>
> thanks,
> Larry
>
>
>
>
> On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> > wrote:
>
> Hei Larry,
>
> Larry Becker schrieb:
> >  Hi Stefan,
> >
> >  1.  Is there somewhere I can get a copy of the shape file to
> test with?
>
> i upload it here:
>
ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip
>
> >  2.  Is the speed up working for other large shape files?
> i have not tested
> >  3.  Does it perform better if you zoom to full extents
instead
> of using
> >  the Zoom bar.
> yes - (or as usual)
> >  4.  What is the Committed Memory showing after you load the
file?
> mhm.. not that much: 11MB
> >  5.  After the blocked behavior, does the Committed Memory go
> down?
> 14 MB
>
> btw: panning is fine, and if i use Zoom to scale it is fine as
well.
>
> thanx for taking care
> stefan :)
>
> >
> >   Thanks for testing.  I have been waiting for other
developers
> to try
&g

Re: [JPP-Devel] speed up of rendering

2007-03-26 Thread Pedro Doria Meunier 
Hi guys

 

This is what I use in my command line with really improved performance:

 

start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m -XX:NewSize=24m
-XX:SurvivorRatio=128 

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 

-XX:CMSInitiatingOccupancyFraction=60 

-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel 

-Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp %CLASSPATH% 

com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en -properties 

workbench-properties.xml -plug-in-directory %LIB%/ext

 

Note the -XX:ParallelGCThreads=2 switch… everyone with an hyperthreading or
dual-core processor should use this… ;-)

There’s also some trickery around the garbage collector policies.

 

Best regards,

Pedro.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of erwan
bocher
Sent: domingo, 25 de Março de 2007 10:57
To: List for discussion of JPP development and use.
Subject: Re: [JPP-Devel] speed up of rendering

 

Hi,

One remark about memory consumed  in OJ. When I load a shapefile with 36 580
polygons (size 18 mb) the memory using by my java virtual is up to 202 mb.
If I minimize my OpenJUMP windows and I open it again the JVM display : 85
mb. 

R1.




On 3/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:

you are right.. if i click on the zoombar.. then everything seems to be
faster(=normal) with my modified version.

I actually see the slow behaviour too if i move the slider with an older
jump version and a jump-i18n version (which is a bit odd, since the 
other version i did test for comparing was a newer openjump-cvs version
from august last year.. so somebody did something change in between)

Btw.. there is no need to fix that now.. weekends should be weekends ;) 

stefan

Larry Becker schrieb:
> Hi Stefan,
>
>I seem to be duplicating the Zoom bar behavior you reported without
> the speed mod.  If I click and drag the zoom bar slider, I get very slow 
> redraw times on the order of ten seconds, however If I click the zoom
> bar it is faster.  I think JUMP is starting multiple render threads
> while the zoom bar slider is being dragged.  This could explain the slow 
> behavior.  Also the very large polygons that you are testing with don't
> seem to be simplified by the ZoomBar's randomGeometries() unless the
> number of geometries is greater than 100.
> 
> Can you test it again and see if the large slowdown only occurs when you
> drag the zoom bar (in any version of JUMP).
>
> thanks,
> Larry
>
> On 3/24/07, * Larry Becker* < <mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi Stefan,
>
>   It occurs to me that I never use the Zoom bar so I probably 
> haven't tested it.   The Zoom bar does a more radical kind of
> decimation simplification itself.  It might be interacting with the
> Java2DConverter decimation in a bad way.  I'll check it out. 
>
> thanks,
> Larry
>
>
>
>
> On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> mailto:[EMAIL PROTECTED]>  [EMAIL PROTECTED]>> wrote:
>
> Hei Larry,
>
> Larry Becker schrieb:
> >  Hi Stefan,
> >
> >  1.  Is there somewhere I can get a copy of the shape file to 
> test with?
>
> i upload it here:
>  ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip

>
> >  2.  Is the speed up working for other large shape files?
> i have not tested
> >  3.  Does it perform better if you zoom to full extents instead
> of using 
> >  the Zoom bar.
> yes - (or as usual)
> >  4.  What is the Committed Memory showing after you load the
file?
> mhm.. not that much: 11MB
> >  5.  After the blocked behavior, does the Committed Memory go 
> down?
> 14 MB
>
> btw: panning is fine, and if i use Zoom to scale it is fine as
well.
>
> thanx for taking care
> stefan :)
>
> >
> >   Thanks for testing.  I have been waiting for other developers
> to try
> >  the decimator mod to see if there might be issues.
> >
> >  regards,
> >  Larry
> >
> >  On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> 
> >  mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >>> wrote:
> >
> > Hei Larry and Bob,
> >
> > i did test somthing after i implemented the new speed up
code.
> > I loaded a large shp file with 16 very large polygons (> 
> 5000 points)

Re: [JPP-Devel] speed up of rendering

2007-03-25 Thread Pedro Doria Meunier 
Hi guys

 

This is what I use in my command line with really improved performance:

 

start javaw -XX:ParallelGCThreads=2 -XX:MaxNewSize=24m -XX:NewSize=24m
-XX:SurvivorRatio=128 

 

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 

 

-XX:CMSInitiatingOccupancyFraction=60 

 

-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel 

 

-Dlog4j.configuration=file:./log4j.xml -Xms1024M -Xmx1024M -cp %CLASSPATH% 

 

com.vividsolutions.jump.workbench.JUMPWorkbench -i18n en -properties 

 

workbench-properties.xml -plug-in-directory %LIB%/ext

 

Note the -XX:ParallelGCThreads=2 switch… everyone with an hyperthreading or
dual-core processor should use this… ;-)

There’s also some trickery around the garbage collector policies.

 

Best regards,

Pedro.

 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of erwan
bocher
Sent: domingo, 25 de Março de 2007 10:57
To: List for discussion of JPP development and use.
Subject: Re: [JPP-Devel] speed up of rendering

 

Hi,

One remark about memory consumed  in OJ. When I load a shapefile with 36 580
polygons (size 18 mb) the memory using by my java virtual is up to 202 mb.
If I minimize my OpenJUMP windows and I open it again the JVM display : 85
mb. 

R1.



 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-25 Thread erwan bocher 

Hi,

One remark about memory consumed  in OJ. When I load a shapefile with 36 580
polygons (size 18 mb) the memory using by my java virtual is up to 202 mb.
If I minimize my OpenJUMP windows and I open it again the JVM display : 85
mb.

R1.



On 3/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:


you are right.. if i click on the zoombar.. then everything seems to be
faster(=normal) with my modified version.

I actually see the slow behaviour too if i move the slider with an older
jump version and a jump-i18n version (which is a bit odd, since the
other version i did test for comparing was a newer openjump-cvs version
from august last year.. so somebody did something change in between)

Btw.. there is no need to fix that now.. weekends should be weekends ;)

stefan

Larry Becker schrieb:
> Hi Stefan,
>
>I seem to be duplicating the Zoom bar behavior you reported without
> the speed mod.  If I click and drag the zoom bar slider, I get very slow
> redraw times on the order of ten seconds, however If I click the zoom
> bar it is faster.  I think JUMP is starting multiple render threads
> while the zoom bar slider is being dragged.  This could explain the slow
> behavior.  Also the very large polygons that you are testing with don't
> seem to be simplified by the ZoomBar's randomGeometries() unless the
> number of geometries is greater than 100.
>
> Can you test it again and see if the large slowdown only occurs when you
> drag the zoom bar (in any version of JUMP).
>
> thanks,
> Larry
>
> On 3/24/07, * Larry Becker* <[EMAIL PROTECTED]
> > wrote:
>
> Hi Stefan,
>
>   It occurs to me that I never use the Zoom bar so I probably
> haven't tested it.   The Zoom bar does a more radical kind of
> decimation simplification itself.  It might be interacting with the
> Java2DConverter decimation in a bad way.  I'll check it out.
>
> thanks,
> Larry
>
>
>
>
> On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> > wrote:
>
> Hei Larry,
>
> Larry Becker schrieb:
> >  Hi Stefan,
> >
> >  1.  Is there somewhere I can get a copy of the shape file to
> test with?
>
> i upload it here:
>
ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip
>
> >  2.  Is the speed up working for other large shape files?
> i have not tested
> >  3.  Does it perform better if you zoom to full extents
instead
> of using
> >  the Zoom bar.
> yes - (or as usual)
> >  4.  What is the Committed Memory showing after you load the
file?
> mhm.. not that much: 11MB
> >  5.  After the blocked behavior, does the Committed Memory go
> down?
> 14 MB
>
> btw: panning is fine, and if i use Zoom to scale it is fine as
well.
>
> thanx for taking care
> stefan :)
>
> >
> >   Thanks for testing.  I have been waiting for other
developers
> to try
> >  the decimator mod to see if there might be issues.
> >
> >  regards,
> >  Larry
> >
> >  On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> 
> >  mailto:[EMAIL PROTECTED]>>>
wrote:
> >
> > Hei Larry and Bob,
> >
> > i did test somthing after i implemented the new speed up
code.
> > I loaded a large shp file with 16 very large polygons (>
> 5000 points)
> > and zoom to full extent.
> > When i moved the slider of the zoom bar (zooming out) the
> systems does
> > nothing (is blocked) for more than 30 seconds (or even
more).
> > If make the same thing with an older version of jump it
> takes one 2 sek
> > after seeing the outlines and one sec more for filling.
> >
> > any suggestions?
> > probably an issue which could be solved by the bbox?
> >
> > stefan
> >
> > Larry Becker schrieb:
> >  > Right.  That would be:
> >  >
> >  >
> >
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
> >  > <
> >
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
>
> >  >
> >  > with an incidental mod to:
> >  >
> >  >
> >
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
> <
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>
> >  > <
> >
>
http://skyjump.cvs.sourceforge.net/skyjump/s

Re: [JPP-Devel] speed up of rendering

2007-03-24 Thread Stefan Steiniger 
you are right.. if i click on the zoombar.. then everything seems to be 
faster(=normal) with my modified version.

I actually see the slow behaviour too if i move the slider with an older 
jump version and a jump-i18n version (which is a bit odd, since the 
other version i did test for comparing was a newer openjump-cvs version 
from august last year.. so somebody did something change in between)

Btw.. there is no need to fix that now.. weekends should be weekends ;)

stefan

Larry Becker schrieb:
> Hi Stefan,
> 
>I seem to be duplicating the Zoom bar behavior you reported without 
> the speed mod.  If I click and drag the zoom bar slider, I get very slow 
> redraw times on the order of ten seconds, however If I click the zoom 
> bar it is faster.  I think JUMP is starting multiple render threads 
> while the zoom bar slider is being dragged.  This could explain the slow 
> behavior.  Also the very large polygons that you are testing with don't 
> seem to be simplified by the ZoomBar's randomGeometries() unless the 
> number of geometries is greater than 100.
> 
> Can you test it again and see if the large slowdown only occurs when you 
> drag the zoom bar (in any version of JUMP).
> 
> thanks,
> Larry
> 
> On 3/24/07, * Larry Becker* <[EMAIL PROTECTED] 
> > wrote:
> 
> Hi Stefan,
> 
>   It occurs to me that I never use the Zoom bar so I probably
> haven't tested it.   The Zoom bar does a more radical kind of
> decimation simplification itself.  It might be interacting with the
> Java2DConverter decimation in a bad way.  I'll check it out.
> 
> thanks,
> Larry
> 
> 
> 
> 
> On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> > wrote:
> 
> Hei Larry,
> 
> Larry Becker schrieb:
> >  Hi Stefan,
> >
> >  1.  Is there somewhere I can get a copy of the shape file to
> test with?
> 
> i upload it here:
>  ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip
> 
> >  2.  Is the speed up working for other large shape files?
> i have not tested
> >  3.  Does it perform better if you zoom to full extents instead
> of using
> >  the Zoom bar.
> yes - (or as usual)
> >  4.  What is the Committed Memory showing after you load the file?
> mhm.. not that much: 11MB
> >  5.  After the blocked behavior, does the Committed Memory go
> down?
> 14 MB
> 
> btw: panning is fine, and if i use Zoom to scale it is fine as well.
> 
> thanx for taking care
> stefan :)
> 
> >
> >   Thanks for testing.  I have been waiting for other developers
> to try
> >  the decimator mod to see if there might be issues.
> >
> >  regards,
> >  Larry
> >
> >  On 3/24/07, *Stefan Steiniger* < [EMAIL PROTECTED]
> 
> >  mailto:[EMAIL PROTECTED]>>> wrote:
> >
> > Hei Larry and Bob,
> >
> > i did test somthing after i implemented the new speed up code.
> > I loaded a large shp file with 16 very large polygons (>
> 5000 points)
> > and zoom to full extent.
> > When i moved the slider of the zoom bar (zooming out) the
> systems does
> > nothing (is blocked) for more than 30 seconds (or even more).
> > If make the same thing with an older version of jump it
> takes one 2 sek
> > after seeing the outlines and one sec more for filling.
> >
> > any suggestions?
> > probably an issue which could be solved by the bbox?
> >
> > stefan
> >
> > Larry Becker schrieb:
> >  > Right.  That would be:
> >  >
> >  >
> >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
> >  > <
> >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log>
> >  >
> >  > with an incidental mod to:
> >  >
> >  >
> >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
> 
> 
> >  > <
> >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
> 
>

Re: [JPP-Devel] speed up of rendering

2007-03-24 Thread Larry Becker 

Hi Stefan,

  I seem to be duplicating the Zoom bar behavior you reported without the
speed mod.  If I click and drag the zoom bar slider, I get very slow redraw
times on the order of ten seconds, however If I click the zoom bar it is
faster.  I think JUMP is starting multiple render threads while the zoom bar
slider is being dragged.  This could explain the slow behavior.  Also the
very large polygons that you are testing with don't seem to be simplified by
the ZoomBar's randomGeometries() unless the number of geometries is greater
than 100.

Can you test it again and see if the large slowdown only occurs when you
drag the zoom bar (in any version of JUMP).

thanks,
Larry

On 3/24/07, Larry Becker <[EMAIL PROTECTED]> wrote:


Hi Stefan,

  It occurs to me that I never use the Zoom bar so I probably haven't
tested it.   The Zoom bar does a more radical kind of decimation
simplification itself.  It might be interacting with the Java2DConverter
decimation in a bad way.  I'll check it out.

thanks,
Larry



On 3/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
>
> Hei Larry,
>
> Larry Becker schrieb:
> > Hi Stefan,
> >
> >  1.  Is there somewhere I can get a copy of the shape file to test
> with?
>
> i upload it here:
>  ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip
>
> >  2.  Is the speed up working for other large shape files?
> i have not tested
> >  3.  Does it perform better if you zoom to full extents instead of
> using
> > the Zoom bar.
> yes - (or as usual)
> >  4.  What is the Committed Memory showing after you load the file?
> mhm.. not that much: 11MB
> >  5.  After the blocked behavior, does the Committed Memory go down?
> 14 MB
>
> btw: panning is fine, and if i use Zoom to scale it is fine as well.
>
> thanx for taking care
> stefan :)
>
> >
> >   Thanks for testing.  I have been waiting for other developers to try
> > the decimator mod to see if there might be issues.
> >
> > regards,
> > Larry
> >
> > On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hei Larry and Bob,
> >
> > i did test somthing after i implemented the new speed up code.
> > I loaded a large shp file with 16 very large polygons (> 5000
> points)
> > and zoom to full extent.
> > When i moved the slider of the zoom bar (zooming out) the systems
> does
> > nothing (is blocked) for more than 30 seconds (or even more).
> > If make the same thing with an older version of jump it takes one
> 2 sek
> > after seeing the outlines and one sec more for filling.
> >
> > any suggestions?
> > probably an issue which could be solved by the bbox?
> >
> > stefan
> >
> > Larry Becker schrieb:
> >  > Right.  That would be:
> >  >
> >  >
> >
> 
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
> >  > <
> >
> 
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
> >
> >  >
> >  > with an incidental mod to:
> >  >
> >  >
> > 
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>
> >  > <
> > 
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
> >
> >  >
> >  > regards,
> >  > Larry
> >  >
> >
> >
> -
> >
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys-and earn
> cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > 
 >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > 
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > 
> >
> >
> >
> >
> > --
> > http://amusingprogrammer.blogspot.com/
> >
> >
> >
> 
> >
> >
> -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> >
> >
> 
> >
> > ___
> > Jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-24 Thread Larry Becker 

Hi Stefan,

 It occurs to me that I never use the Zoom bar so I probably haven't tested
it.   The Zoom bar does a more radical kind of decimation simplification
itself.  It might be interacting with the Java2DConverter decimation in a
bad way.  I'll check it out.

thanks,
Larry



On 3/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:


Hei Larry,

Larry Becker schrieb:
> Hi Stefan,
>
>  1.  Is there somewhere I can get a copy of the shape file to test with?

i upload it here:
ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip

>  2.  Is the speed up working for other large shape files?
i have not tested
>  3.  Does it perform better if you zoom to full extents instead of using
> the Zoom bar.
yes - (or as usual)
>  4.  What is the Committed Memory showing after you load the file?
mhm.. not that much: 11MB
>  5.  After the blocked behavior, does the Committed Memory go down?
14 MB

btw: panning is fine, and if i use Zoom to scale it is fine as well.

thanx for taking care
stefan :)

>
>   Thanks for testing.  I have been waiting for other developers to try
> the decimator mod to see if there might be issues.
>
> regards,
> Larry
>
> On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED]
> > wrote:
>
> Hei Larry and Bob,
>
> i did test somthing after i implemented the new speed up code.
> I loaded a large shp file with 16 very large polygons (> 5000
points)
> and zoom to full extent.
> When i moved the slider of the zoom bar (zooming out) the systems
does
> nothing (is blocked) for more than 30 seconds (or even more).
> If make the same thing with an older version of jump it takes one 2
sek
> after seeing the outlines and one sec more for filling.
>
> any suggestions?
> probably an issue which could be solved by the bbox?
>
> stefan
>
> Larry Becker schrieb:
>  > Right.  That would be:
>  >
>  >
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
>  > <
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
>
>  >
>  > with an incidental mod to:
>  >
>  >
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>  > <
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>
>  >
>  > regards,
>  > Larry
>  >
>
>
-
>
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> <
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
>
>
>
>
> --
> http://amusingprogrammer.blogspot.com/
>
>
> 
>
>
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> 
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel





--
http://amusingprogrammer.blogspot.com/
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
htt

Re: [JPP-Devel] speed up of rendering

2007-03-24 Thread Stefan Steiniger 
Hei Larry,

Larry Becker schrieb:
> Hi Stefan,
> 
>  1.  Is there somewhere I can get a copy of the shape file to test with?

i upload it here:
ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip

>  2.  Is the speed up working for other large shape files? 
i have not tested
>  3.  Does it perform better if you zoom to full extents instead of using 
> the Zoom bar.
yes - (or as usual)
>  4.  What is the Committed Memory showing after you load the file?
mhm.. not that much: 11MB
>  5.  After the blocked behavior, does the Committed Memory go down?
14 MB

btw: panning is fine, and if i use Zoom to scale it is fine as well.

thanx for taking care
stefan :)

> 
>   Thanks for testing.  I have been waiting for other developers to try 
> the decimator mod to see if there might be issues.
> 
> regards,
> Larry
> 
> On 3/24/07, *Stefan Steiniger* <[EMAIL PROTECTED] 
> > wrote:
> 
> Hei Larry and Bob,
> 
> i did test somthing after i implemented the new speed up code.
> I loaded a large shp file with 16 very large polygons (> 5000 points)
> and zoom to full extent.
> When i moved the slider of the zoom bar (zooming out) the systems does
> nothing (is blocked) for more than 30 seconds (or even more).
> If make the same thing with an older version of jump it takes one 2 sek
> after seeing the outlines and one sec more for filling.
> 
> any suggestions?
> probably an issue which could be solved by the bbox?
> 
> stefan
> 
> Larry Becker schrieb:
>  > Right.  That would be:
>  >
>  >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
>  > <
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log>
>  >
>  > with an incidental mod to:
>  >
>  >
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>  > <
> 
> http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log>
>  >
>  > regards,
>  > Larry
>  >
> 
> -
> 
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
> 
> 
> 
> 
> -- 
> http://amusingprogrammer.blogspot.com/
> 
> 
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> 
> 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] speed up of rendering

2007-03-24 Thread Larry Becker 

Hi Stefan,

1.  Is there somewhere I can get a copy of the shape file to test with?
2.  Is the speed up working for other large shape files?
3.  Does it perform better if you zoom to full extents instead of using the
Zoom bar.
4.  What is the Committed Memory showing after you load the file?
5.  After the blocked behavior, does the Committed Memory go down?

 Thanks for testing.  I have been waiting for other developers to try the
decimator mod to see if there might be issues.

regards,
Larry

On 3/24/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:


Hei Larry and Bob,

i did test somthing after i implemented the new speed up code.
I loaded a large shp file with 16 very large polygons (> 5000 points)
and zoom to full extent.
When i moved the slider of the zoom bar (zooming out) the systems does
nothing (is blocked) for more than 30 seconds (or even more).
If make the same thing with an older version of jump it takes one 2 sek
after seeing the outlines and one sec more for filling.

any suggestions?
probably an issue which could be solved by the bbox?

stefan

Larry Becker schrieb:
> Right.  That would be:
>
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
> <
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/java2D/Java2DConverter.java?view=log
>
>
> with an incidental mod to:
>
>
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
> <
http://skyjump.cvs.sourceforge.net/skyjump/skyjump/com/vividsolutions/jump/workbench/ui/renderer/style/WKTFillPattern.java?view=log
>
>
> regards,
> Larry
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel





--
http://amusingprogrammer.blogspot.com/
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel