Re: [JPP-Devel] NB from intevation
Hi! On 24.05.2012 02:32, Edgar Soldin wrote: On 23.05.2012 22:30, Michaël Michaud wrote: Hi, Wonder if there is a technical reason why the NB built by intevation stopped on May, 10th at http://jump-pilot.sourceforge.net/download/nightlybuild/ i wrote them about it and wait for an answer. probably they are going to stop builds as we have my snapshots already, but i asked them to continue the service if only as a backup in case my server dies. @sascha: any news on this? We have decided to continue the builds. Inconveniently I'am on a heavy workload atm. I hope I'll find some time next week to make the nightlys work again. Stay tuned. Regards, Sascha -- teichm...@intevation.de | ++49-(0) 541-33 50 83-636 | http://www.intevation.de software architect and senior developer Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [PATCH] mvn exec:java
Am 16.03.2012 22:55, schrieb Stefan Steiniger: fortunately Michael was faster in doing the commit :) thanks Sascha and good to know you are still around. stefan On 16/03/2012 3:12 PM, Michaël Michaud wrote: Thanks Sascha, Nice to know you're still working with OpenJUMP Your patch is committed. Remember you still have commit rights for the project. Your contributions are welcome ;-) Nice to know OJ is working on small devices with android. I think some OJ project members were interested. Michaël Yes, I'm still around. ;-) Thank you for applying the patch. It eases compiling and running OpenJUMP by only having subversion, a JDK and maven2 installed. Of cause you can use the bundled start scripts but for a quick-fix, compile and run turn-around loop this way is more convenient IMHO. I'm currently playing around with Android and have set up a Debian/Sid/armhf chroot environment on my tablet which allows me to run OpenJUMP with OpenJDK6, too. A photo of OpenJUMP running on this setup can be found here [1]. I've shown it to Matthias Scholz at the FOSSGIS, who btw did a greater job there to promote OpenJUMP *thumbs up*. Building a native OpenJUMP on Android (without the chroot) would be an interesting task with a lot of work near to the point of infeasibility (maybe beyond). I've given some thought about this, but this discussion would be a nice topic for a separate thread. ;-) - Sascha [1] http://dl.dropbox.com/u/23366205/openjump/openjump-on-tablet.jpg -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [PATCH] mvn exec:java
Hi!
When running OpenJUMP with
$ mvn -Dexec.mainClass=com.vividsolutions.jump.workbench.JUMPWorkbench
exec:java
I run into:
java.lang.NullPointerException
at javax.swing.ImageIcon.init(ImageIcon.java:204)
at org.openide.awt.IconWithArrow.init(IconWithArrow.java:66)
at
org.openide.awt.DropDownToggleButton.updateIcons(DropDownToggleButton.java:294)
at
org.openide.awt.DropDownToggleButton.setIcon(DropDownToggleButton.java:278)
at
org.openide.awt.DropDownToggleButton.init(DropDownToggleButton.java:96)
at
org.openide.awt.DropDownButtonFactory.createDropDownToggleButton(DropDownButtonFactory.java:96)
at
org.openjump.core.ui.plugin.tools.AdvancedMeasureTool.init(AdvancedMeasureTool.java:100)
at
com.vividsolutions.jump.workbench.JUMPConfiguration.configureToolBar(JUMPConfiguration.java:1385)
at
com.vividsolutions.jump.workbench.JUMPConfiguration.setup(JUMPConfiguration.java:369)
at
com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:379)
at
com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:344)
This can be resolved by applying the attached patch IconWithArrow.java.diff
BTW: OJ runs pretty nice in a Debian/sid/armhf chroot + LXDE/VNC on
an Asus Transformer Prime with Android 4.0.3.
Regard,
Sascha
Index: src/org/openide/awt/IconWithArrow.java
===
--- src/org/openide/awt/IconWithArrow.java (Revision 2773)
+++ src/org/openide/awt/IconWithArrow.java (Arbeitskopie)
@@ -59,11 +59,11 @@
*/
class IconWithArrow implements Icon {
-private static final String ARROW_IMAGE_NAME = org/openide/awt/resources/arrow.png; //NOI18N
+private static final String ARROW_IMAGE_NAME = resources/arrow.png; //NOI18N
private Icon orig;
//modified for OJprivate Icon arrow = ImageUtilities.loadImageIcon(ARROW_IMAGE_NAME, false);
- private Icon arrow = new ImageIcon(ClassLoader.getSystemResource(ARROW_IMAGE_NAME));
+ private Icon arrow = new ImageIcon(IconWithArrow.class.getResource(ARROW_IMAGE_NAME));
private boolean paintRollOver;
private static final int GAP = 6;
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Nightly build broken/repared
Hi, Am 12.10.2010 08:43, schrieb Michaël Michaud: Hi, I've broken the nightly build on sunday (last NB is from 2010-10-10). It should be repared from now on and we should have a new NB tomorrow. Sorry for the trouble. Michaël Thank you for fixing it. In case you do not know it already you can find the error logs of the nightly builds at http://gisbuild.intevation.de/openjump/errors/ Regards, Sascha -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] nightly snapshot
Hi! I'm going to write a little cron'd script which will - check out the source from SVN - start an ant build - push the result to our site I only need to talk to the administration which of our build servers is best suited for this, but this is a mere formality. Stay tuned ... - Sascha Stefan Steiniger schrieb: Sascha, that are great news +1 if you can make a nightly built available :) stefan [EMAIL PROTECTED] schrieb: Hi guys! If you still need capacity to build and host the nightlies, Intevation is willing to give you all you need. :-) kind regards, Sascha L. Teichmann Am Donnerstag, 31. Januar 2008 05:27:03 schrieb Jonathan Aquino: Hi guys - the computer that I was using to do the build finally died. Would someone be willing to set up a build on their server? Jon -Original Message- From: Larry Becker [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 1:46 PM To: List for discussion of JPP development and use.; Jonathan Aquino Subject: nightly snapshot The nightly snapshot of OpenJump seems to be empty. http://jonaquino.textdriven.com/openjump_nightly_builds/ Larry -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] nightly snapshot
I have still a few question. * What about security? Ant has tasks like exec which may be a fine way to compromise a build server. Was the old build process jailed in a way? * How much traffic is to be expected? Are there any statistics available? Maybe its a good idea to balance the traffic by publishing the binaries on more than one side. - Sascha Sunburned Surveyor schrieb: Sascha, I really appreciate the willingness to help in this way. Thank you so much! Landon On Jan 31, 2008 1:12 PM, Sascha L. Teichmann [EMAIL PROTECTED] wrote: Hi! I'm going to write a little cron'd script which will - check out the source from SVN - start an ant build - push the result to our site I only need to talk to the administration which of our build servers is best suited for this, but this is a mere formality. Stay tuned ... - Sascha Stefan Steiniger schrieb: Sascha, that are great news +1 if you can make a nightly built available :) stefan [EMAIL PROTECTED] schrieb: Hi guys! If you still need capacity to build and host the nightlies, Intevation is willing to give you all you need. :-) kind regards, Sascha L. Teichmann Am Donnerstag, 31. Januar 2008 05:27:03 schrieb Jonathan Aquino: Hi guys - the computer that I was using to do the build finally died. Would someone be willing to set up a build on their server? Jon -Original Message- From: Larry Becker [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 1:46 PM To: List for discussion of JPP development and use.; Jonathan Aquino Subject: nightly snapshot The nightly snapshot of OpenJump seems to be empty. http://jonaquino.textdriven.com/openjump_nightly_builds/ Larry -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] nightly snapshot
Hi! Larry Becker schrieb: Hi Sascha, Maybe its a good idea to balance the traffic by publishing the binaries on more than one side. I'll be happy to host a mirror for this side of the world. Larry Perfect! :-) But the security issue remains. I still have to figure out, how easy it is to get a virtual machine, a chroot or something similiar which is isolated enough for secure building. I hope that won't be a show stopper. On Jan 31, 2008 4:34 PM, Sunburned Surveyor [EMAIL PROTECTED] wrote: Sascha, I can't answer the security question, but I think you'll find the nightly build is used mostly be our active developers. If we can ever get on a regular schedule for our official releases, I think you would see this use drop. Landon On Jan 31, 2008 2:17 PM, Sascha L. Teichmann [EMAIL PROTECTED] wrote: I have still a few question. * What about security? Ant has tasks like exec which may be a fine way to compromise a build server. Was the old build process jailed in a way? * How much traffic is to be expected? Are there any statistics available? Maybe its a good idea to balance the traffic by publishing the binaries on more than one side. - Sascha Sunburned Surveyor schrieb: Sascha, I really appreciate the willingness to help in this way. Thank you so much! Landon On Jan 31, 2008 1:12 PM, Sascha L. Teichmann [EMAIL PROTECTED] wrote: Hi! I'm going to write a little cron'd script which will - check out the source from SVN - start an ant build - push the result to our site I only need to talk to the administration which of our build servers is best suited for this, but this is a mere formality. Stay tuned ... - Sascha Stefan Steiniger schrieb: Sascha, that are great news +1 if you can make a nightly built available :) stefan [EMAIL PROTECTED] schrieb: Hi guys! If you still need capacity to build and host the nightlies, Intevation is willing to give you all you need. :-) kind regards, Sascha L. Teichmann Am Donnerstag, 31. Januar 2008 05:27:03 schrieb Jonathan Aquino: Hi guys - the computer that I was using to do the build finally died. Would someone be willing to set up a build on their server? Jon -Original Message- From: Larry Becker [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 1:46 PM To: List for discussion of JPP development and use.; Jonathan Aquino Subject: nightly snapshot The nightly snapshot of OpenJump seems to be empty. http://jonaquino.textdriven.com/openjump_nightly_builds/ Larry -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Please use the ChangeLog!
Hi together! We have a ChangeLog file now. It would be very nice to use it. I know this needs a bit of adaption and discipline ... Michaël? Regards, Sascha - 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] Rendering problems affecting the quality of printing
@Larry: IIRC the zero policy was introduced by Sun as a reaction to some user complains at bugs.sun.com that lines were vanishing when the scale becomes very small. I can't remember when that was done. Before 1.4? @SS: What do you think does Batik? It simply creates line x1=.. y1=... x2=... y2=.../ elements from g2d.lineTo(new Line.Double(..)) calls and same for other geometries. There is no magic in there. These primitives are generated by a Java2DConverter which takes a JTS geometry as an input. In pure terms of geometry they are identical! Okay .. at the moment they are piped through Larry's decimating Java2DConverter, but I'm going to check-in the PreciseJava2DConverter from the Print/Layout plug-in as temporal replacement (see Viewport.setJava2DConverter()). This will improve Stefan's SVG plug-in. The only thing that will make the SVG look different will be a different styling. The right sizes of the graphical attributes must have a physical measure. The output medium has to have a physical measure. Than you can determine the right scales. What we need is a concept of a physical size based output device. Renderers must be aware of this. This leads to a lot of refactoring. As an alternative we can build a complete new rendering path, which has to be consistent with the old one. WYSIWYG is another word that comes to mind. What if someone add a new Layerable with new Renderers? Should she or he implement the same logic twice? - Sascha Sunburned Surveyor schrieb: Larry, I know it is very easy to convert to SVG by using the JTS graphics painted on the LayerViewPanel and the Batik libs. I wonder if some of the problems could be eliminated by using the JTS Goemetries and Layer styling information to convert directly to SVG. Just a thought. The Sunburned Surveyor On 6/29/07, Larry Becker [EMAIL PROTECTED] wrote: More surprises (for me). Someone stop me if this is already documented. If you set the line width to zero, you get very faint lines. The documentation for BasicStroke says, If width is set to 0.0f, the stroke is rendered as the thinnest possible line for the target device and the antialias hint setting. Apparently when you create a new layer, the line width defaults to 1. I never noticed that you could drag it left to 0, or if I did I must have assumed it was an error. This could be very handy when you are printing and the lines are showing up too wide on the print device, or just when you have a lot of linestrings very close together. regards, Larry On 6/28/07, Larry Becker [EMAIL PROTECTED] wrote: Interesting... It turns out that when rendering antialiased lines, Java2D actually draws lines with fractional widths as shown in the attached JumpWindow screen capture. This would make it possible to modify the Change Style line width slider to support floating point values that represent very thin lines. Larry On 6/28/07, Larry Becker [EMAIL PROTECTED] wrote: To give a better idea of problem (1), I have attached two jpegs. They were made by doing a screen capture within Inkscape while zoomed to 800%. They are labeled before and after and show the effects of scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG files were created using Stefan's Print Image in SVG Format. Other printing plug-ins may already be implementing their own solutions. regards, Larry Becker On 6/26/07, Sunburned Surveyor [EMAIL PROTECTED] wrote: Larry, This is a great post. Thanks for documenting some of the problems we are having with the rendering system. Perhaps I need to take a crack at these with my pluggable renderering system, instead of stand alone labels. I'll give this some thought. The Sunburned Surveyor On 6/25/07, Larry Becker [EMAIL PROTECTED] wrote: The purpose of this thread is to document problems with BasicStyle rendering that primarily affect the quality of printing plug-ins Problem (1): BasicStyle lineStroke defaults to width 1. See Geoff's About Line Decorations and Printing thread in the archives: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html Proposed solution (1.A): The problem seems to me that JUMP is starting out with the line width way too large. In other applications I have used much smaller default line widths. In order to do this we would need to modify BasicStyle.setLineWidth(int lineWidth) to use a float instead of an int and change setLineWidth(1) to setLineWidth(0.1) or something smaller in the constructor. Problem (2): The relative scale of symbols and text changes when changing from screen resolution to printer resolution. See Geoff's Re: [JPP-Devel] JumpPrinter thread in the archives: http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html Proposed solution (2.A): I haven't thought this one through very well, but it would seem that we need to have some sort of renderer DPI setting (there's those pesky english units
Re: [JPP-Devel] JTS/CursorTool side effects with shared vertices from shapefile?
Sunburned Surveyor schrieb: [...] Sascha's idea about eliminating duplicate coordinate objects in large polygon layers and linesting layers is interesting. I have some questions for him on that, but I will put them in another thread so things don't get so confusing. [...] If they are worthy a new thread ... [...] I'm sorry if I confused things. I didn't say we should implement Sascha's idea, just that I thought it was interesting. :] For now: We have side effects. Martin has at least one plug-in which modifies coordinates in place, Michaël is modifying z-values in place, Larry stated that the ISA tools are full of coord.x = ... stuff. My initial question was asking for side effects so I see these facts as show stoppers for the idea. It would be nice to have a immutable policy for coords and geometries but we'll have to catch all the horses first. (Another annoying lock-in problem of a plug-in system that is open too wide ... - 2¢) BTW: I'm not sure if the CoordinateSequence idea will save a lot of memory. It may be right that the data is packed more tightly and the object overhead would be trimmed, but we might also see a lot of temporal garbage when using the data. JTS is not 'streamlined' with this idea so I suspect a lot of internal 'new Coordinate(..)'s when we're transforming the data (e.g rendering). AFAIK the packed versions of CoordinateSequence have a SoftReference cache mechanism for toArray() inside. I don't know how often this is really called, but objects hanging at SoftReference tombstones are kept quiet long by the GC. ... Just as a hint. Evaluating this maybe connected with some work and at the end it might turn out that there will be probably little to no gain. If we further take into account that only large data sets with a lot of shared vertices will profit from this I would recommend to think about the ratio effort/work. Regards, Sascha - 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] RenderManager optimized for Interactive vs. batch processing
Larry, Larry Becker schrieb: [...] I'm hoping someone will verify that this solution works for printing plugins. I will implement a path for the Print/Layout plug-in to be able to test it. I'm quiet a bit busy at the moment so results will only be available in two days. [...] Regards, Sascha - 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] RenderManager optimized for Interactive vs. batch processing
Hi Larry,
I was so happy that you proposed a 'minimal inversive' solution, but I
think it needs at least some tweaking.
Let's have a look at the relevant part of ZoomToSelectedItemsPlugIn.zoom():
1 -- panel.getRenderingManager().setInteractiveMode(false);
2 -- panel.getViewport().zoom(proposedEnvelope);
3 -- SwingUtilities.invokeLater(new Runnable() {
public void run() {
try {
flash(geometries, panel);
} catch (NoninvertibleTransformException e) {
}
}});
4 -- panel.getRenderingManager().setInteractiveMode(true);
After switching to non-interactive mode (1) all Renderer Runnables
produced by the RenderingManager are directly executed in the
event dispatch thread. This would be done in a render() method
of JUMP's RenderingMaanager. Unfortunately this will not happen!
If you call the Viewport.zoom method (2) the last thing inside this is
a repaint() against the LayerViewPanel. This repaint() lets the
Swing(!) RenderingManager of this component enqueue a Runnable
to the event display thread for later execution. Inside this
Runnable the render*() calls of *JUMPs will be executed. But for
the moment this is only scheduled.
After you've enqueued the flash Runnable (3) the internal event
dispatch queue will look like the following.
[a: Runnable from repaint -- render*()], [b: Runnable to flash]
This would be fine too because _iff_ the RenderingManager would
be in the non-interactive mode at the time of execution of a.
Then the Renderers would be executed directly via
GUIUtil.invokeOnEventThread(). So they would be executed before b.
But now the problem: Now you are doing 4, switching JUMP's
RenderingManager directly back to interactive mode.
The jobs a and b are not executed yet.
So when they got executed after the end of
ZoomToSelectedItemsPlugIn.zoom() the RenderingManager is back in
interactive mode and the Renderer Runnables
are not executed with GUIUtil.invokeOnEventThread().
To fix this I would place the 5 call inside the flash Runnable directly
before the flash() call too ensure that JUMPs rendering manager stays in
non-interactive mode as long as needed.
This observations are made under the assumption that
ZoomToSelectedItemsPlugIn.zoom() runs in the event dispatch thread.
If this is not the case the results are not predictable because the
threads will work against each other and race conditions may occur.
But as always: I may be wrong with my analysis and so comments
and critics are welcome. :-)
I'm still a bit concerned that the hole expensive rendering is done
inside the event dispatch thread. I have to test if this may lead to
trouble elsewhere.
Stay tuned,
Sascha
Sascha L. Teichmann schrieb:
Hi Larry,
this definitely a step into the right direction. :-)
Using the event/display thread to serialize the
renderers in the non-interactive mode is a good idea.
Your code looks fine but I will think about the
consequences (blocking GUI, etc.). Of course I
will test it, too. ;-)
Regards, Sascha
Larry Becker schrieb:
The purpose of this thread is to document a problem with RenderManager
and to propose solutions.
The good news:
RenderManager is optimized for the most responsive interactive GUI
experience. It uses multiple threads, image caching, and timed
refresh operations to ensure that the user's perception is that they
never have to wait. IMO JUMP is unrivaled in this respect.
The bad news:
The original JUMP design did not including printing support. Saving a
screen image was the only option. Now we have many options supporting
printing, SVG, PDF, and image export. This is great, but all of them
have to work around RenderManager issues to ensure proper results.
Sometimes a long user-specified delay while WMS or server layers
finish rendering is necessary. This looks unprofessional and is
ultimately unreliable.
Here is the preferred solution as I see it (call it the Interactive
Mode Switch solution):
Make a modification to the RenderManager class to include a new
property called interactiveMode with associated getters and setters.
The interactiveMode property defaults to true. Printing code and
other routines that need batch oriented rendering will need to bracket
their rendering code with calls to setInteractiveMode(false) and
setInteractiveMode(true). In between the calls, rendering operations
are guaranteed to be done on the same thread and block until they
complete.
How this is accomplished:
Again, making modifications only to RenderManager, make the following
changes:
1. In createRenderer() if interactiveMode is true, it should
setMaxFeatures for the Renderer to the maximum integer. This will
disable image caching, causing renderers to paint directly to the
graphics context.
2. in render() if interactiveMode is true, it should run the Renderer
on the event thread instead of using the ThreadQueue. Also it should
not start
Re: [JPP-Devel] RenderManager optimized for Interactive vs. batch processing
Hi Larry, this definitely a step into the right direction. :-) Using the event/display thread to serialize the renderers in the non-interactive mode is a good idea. Your code looks fine but I will think about the consequences (blocking GUI, etc.). Of course I will test it, too. ;-) Regards, Sascha Larry Becker schrieb: The purpose of this thread is to document a problem with RenderManager and to propose solutions. The good news: RenderManager is optimized for the most responsive interactive GUI experience. It uses multiple threads, image caching, and timed refresh operations to ensure that the user's perception is that they never have to wait. IMO JUMP is unrivaled in this respect. The bad news: The original JUMP design did not including printing support. Saving a screen image was the only option. Now we have many options supporting printing, SVG, PDF, and image export. This is great, but all of them have to work around RenderManager issues to ensure proper results. Sometimes a long user-specified delay while WMS or server layers finish rendering is necessary. This looks unprofessional and is ultimately unreliable. Here is the preferred solution as I see it (call it the Interactive Mode Switch solution): Make a modification to the RenderManager class to include a new property called interactiveMode with associated getters and setters. The interactiveMode property defaults to true. Printing code and other routines that need batch oriented rendering will need to bracket their rendering code with calls to setInteractiveMode(false) and setInteractiveMode(true). In between the calls, rendering operations are guaranteed to be done on the same thread and block until they complete. How this is accomplished: Again, making modifications only to RenderManager, make the following changes: 1. In createRenderer() if interactiveMode is true, it should setMaxFeatures for the Renderer to the maximum integer. This will disable image caching, causing renderers to paint directly to the graphics context. 2. in render() if interactiveMode is true, it should run the Renderer on the event thread instead of using the ThreadQueue. Also it should not start a repaint timer. These changes effectively eliminate any unsynchronized rendering from RenderManager. See the attached copy of RenderManager for details. - For interactive plug-ins like ZoomToSelectedItems that also need to control rendering order so that the flash operation is synchronized. For ZoomToSelectedItems, in addition to bracketing rendering code with sets, it is also necessary to use invokeLater() on the flash() method so that it will be executed in order with the panel component update. I have tested this solution on both OpenJump and SkyJUMP and it seems to solve the ZoomToSelectedItems flash issue (see attached file for details). I tested on my usual P4 2.4GHz and also on a 1.5GHz Athlon. More testing is needed to determine how well it meets the needs of printing plug-ins. This solution has the advantage that JUMP continues to behave exactly as before until you set the interactiveMode to false. No refactoring of interactive rendering code is necessary. regards, Larry Becker - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A new ThreadQueue
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 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 to do this change and I'm grateful if you could improve this dark part of the code. Michaël 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 rendering system to see if it can be part of the solution. I'm afraid I never really understood what class of problems it was targeted at solving. ;) ..an exercise??? stefan I'll test the less radical ZoomToSelectedItemsPlugIn solution. We may need to make the RenderManager repaint timer duration get and set-able so that we can synchronize better. I'll also take a look at your proposed rendering system changes, but I would also like to investigate a different solution first. I'll report back soon. regards, Larry On 6/20/07, *Sascha L. Teichmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 features for the end users ... 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 that triggers a repaint any x ms. First of all let me state that we are not talking about 'A new ThreadQueue' any more. The problems we discussing now exist with the old and the new one. See below. My main goal in this thread was to bring on a new ThreadQueue. Are we through with this? If yes, I will commit it. I'm not sure that changing the repaint timer setting from 1000 to 400 affects performance significantly. My benchmarks show a 3% increase in render time for burlulc. I'm not sure if that will be true for all platforms and CPUs. There could be some advantage from my Dell's P4 hyper-threading here. I'll have to do more tests on a single CPU to be sure. I did drop the time to 40 ms and got a 22% increase. At that level, Jon's comment about too little happening each repaint rang true. Sorry Larry, setting the the value to 400ms does not solve the problem on my lower end machine. The flash is regularly omitted if I zoom to smaller scales. All the tweaking you are suggesting seems to scale with your horse power (only). A 400 ms repaint timer doesn't solve the problem, but it makes it bearable for zoom to selected. I can't speak to how this affects the printing plugins. For databases and WMSLayers, it isn't the solution. Exactly. And you may be supprised: there are people out there who want to print WMS layers too. Ask Jukka! Are the printing plugins working around this problem now by long delays or what? The Print/Layout plug-in offers an option to set a wait time for this kind of layers with a comment like Sorry dear user, we aren't capable to figure out how long it may take to print this layer. Try several value. Do some nested intervals. Do a little trial and error. IMHO this isn't very cool. Same for zooming. To avoid expensive data import into the Print/Layout plug-in we offer the opportunity to insert previews (screen shots) of the map. Later when the real print is done the data needs to be extracted from the GIS. This involves a zooming to a bookmarked position. Zooming is not reliable. So we have the same waiting options here with the same cheesy comment Sorry, dear user ... I can live with this. As I said a long time ago at the very beginning of this thread: I can explain this to customers, I'm able proof the quirks and I'm also able to show possible solutions. The real interesting question (to me) is: Is it possible in OpenJUMP to correct little design flaws like this? Even if we have to bend the original design a bit? I'll have a keen look at Landons pluggable renderer stuff ... I'm trying to assess the impact of not fixing this issue right now. I don't want to minimize the problem, but I see other more pressing
[JPP-Devel] JTS/CursorTool side effects with shared vertices from shapefile?
Just for curiosity: When I load a larger polygon shapefile (burlulc) I recognized that the geometries share a lot of common vertices. In case of the burlulc layer over 1,500,000. They are represented by com.vividsolutions.jts.geom.Coordinate objects. If a shapefile gets loaded a new Coordinate object for each vertex is created. Now I added a simple TreeMap to the PolygonHandler of OpenJUMP's shapefile reader to reuse already created Coordinate objects and share them with other geometries. After loading the data (+ triggering GC) the normal OJ uses approx. 124MB memory. After the the shared vertices modification OJ uses only approx. 89MB. My question: May this mod lead to any side effects? With JTS? With the CursorTools? Coordinate objects are not immutable, so I expect side effects with e.g. neighboring polygons when I edit one of them. I had a brief look at the code and played with the CursorTools but I haven't found any side effects yet. This idea comes from playing with OJ on a boring friday evening. It only costs me a few seconds to implement and if you say This idea is plain stupid! I'll drop it immediately .. ;-) Kind regards, Sascha - 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] JTS/CursorTool side effects with shared vertices from shapefile?
Thanks for these informations. Martin! :-) I agree with you. Not all kind of data will profit from this. Large polygon layers and maybe lines too. Some heuristics have to be applied here. Implying some spatial coherency, a cache of say the last 35,000 visited vertices as a basis of comparison leads to viable results, even if they are not optimal. I implemented this strategy with a LinkedHashMap and it works fine for my test data. Unfortunately this produces a bit of temporal garbage (the cache) so the saving is not obvious at first glance. (GC helps) If someone wants to test it, I've attached a patch against org.geotools.shapefile.PolygonHandler. I had a look at the JavaDocs of PackedCoordinateSequence Co too. To integrate this into JUMP _really_ leads to some work. @Paul: IIRC Larry and Michaël intern()ed the Strings from DBF files to save a lot of memory. Regards, Sascha Paul Austin schrieb: Another huge memory saving can be done by using String.intern() on string objects as they are immutable anyway. I think the latest VM's do some garbage collection on the intern cache so it's not a bad thing to do. Paul Martin Davis wrote: I'm almost 100% sure that JUMP treats Coordinate objects as immutable (at least in the core code. I do know that at least one plugin I wrote changes the Coordinates in Geometries - my bad!). I think this should be a firm design principle of JUMP - it's simply not worth the risk to mutate Coordinates in-place. The same goes for Geometrys, I think. There's lots of benefits to having immutability, and lots of risks to not having it. So your Coordinate-sharing idea should work. Whether this really makes much of an impact in the general use case I can't say - it's very dependent on the nature of the data being loaded. 50% savings doesn't seem like that much to me - but I guess that depends on whether you are trying to load a 2 GB shapefile! Perhaps this should be called Coordinate-externing, referring to the similar strategy that Java uses for String constants. Another possible option for providing memory savings is to take advantage of the JTS CoordinateSequence facility, and use PackedCoordinateSequences for raw Geometry storage. This might give an even bigger memory savings. But it would *definitely* require changes to the core, since JUMP was mostly written before the JTS CS was introduced, so the code assumes it can get down-and-dirty with the Coordinate arrays in JTS. Sascha L. Teichmann wrote: Just for curiosity: When I load a larger polygon shapefile (burlulc) I recognized that the geometries share a lot of common vertices. In case of the burlulc layer over 1,500,000. They are represented by com.vividsolutions.jts.geom.Coordinate objects. If a shapefile gets loaded a new Coordinate object for each vertex is created. Now I added a simple TreeMap to the PolygonHandler of OpenJUMP's shapefile reader to reuse already created Coordinate objects and share them with other geometries. After loading the data (+ triggering GC) the normal OJ uses approx. 124MB memory. After the the shared vertices modification OJ uses only approx. 89MB. My question: May this mod lead to any side effects? With JTS? With the CursorTools? Coordinate objects are not immutable, so I expect side effects with e.g. neighboring polygons when I edit one of them. I had a brief look at the code and played with the CursorTools but I haven't found any side effects yet. This idea comes from playing with OJ on a boring friday evening. It only costs me a few seconds to implement and if you say This idea is plain stupid! I'll drop it immediately .. ;-) Kind regards, Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Index: src/org/geotools/shapefile/PolygonHandler.java === --- src/org/geotools/shapefile/PolygonHandler.java (Revision 863) +++ src/org/geotools/shapefile/PolygonHandler.java (Arbeitskopie) @@ -3,6 +3,8
Re: [JPP-Devel] Some help with Java I/O...
You wrote
File dataStorageDirectory = new File(argPath);
File toWrite = new File(argPath + argFileName);
Do you intent to write
File dataStorageDirectory = new File(argPath);
File toWrite = new File(argPath, argFileName);
',' instead of '+' for appending a filename to the path?
See JavaDoc for File(String parent, String child).
BTW: If you open an existing file for writing again it
will be overwritten if you write to it. Run the
following to see what I mean:
code
import java.io.*;
public class Test
{
public static void main(String [] args) throws IOException {
String filename = test.txt;
File file = new File(filename);
FileOutputStream out = new FileOutputStream(filename);
byte msg [] = new byte[10];
out.write(msg);
out.close();
System.out.println(first: + file.length());
out = new FileOutputStream(filename);
msg = new byte [1];
out.write(msg);
out.close();
System.out.println(second: + file.length());
}
}
/code
- Sascha
Sunburned Surveyor schrieb:
I had a few minutes after my wife went to bed tonight to work on my
FeatureCache. I'm currently writing code for the BOFFFeatureWriter. In
this class I have a method that sets up a DataOutputStream so I can
write bytes representing the feature to a binary file.
I need to see if a binary file representing the Feature already
exists. If it does exist I need to delete it so the file can be
overwritten. (In the FeatureCache each Feature is saved to a binary
file that has a unique name. This unique name is the same as the
unique number that identifies the Feature object. I don't want to
append the data being written to an existing file, nor do I want to
have two (2) files with different names representing the same Feature
object.)
I haven't written a lot of Java I/O code, so I was hoping one of you
more experienced developers might look at the method I wrote that
prepares the DataOutputStream to see if I had any obvious mistakes or
bugs. I have pasted the method statements in the attached text file.
Thank you for the help.
The Sunburned Surveyor
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Java version
Hi together! It's all about market share between 1.4, 1.5 and 1.6. I have no concrete numbers, but I think 1.4 has still a wide basis these days, even if there are newer version of Java out there. The question you have to answer is: Does my product profit from the new features? I'm not not talking about syntactical sugar (Generics), I'm talking about using the larger library and of things like speed of development, correctness, etc. The original JUMP uses still 1.4 IIRC and I would tend to say this a wise idea if you want to reach customers which are not willing to install a newer JVM (for a number of serious reasons). OpenJUMP is 1.5 mainly because of some PIROL stuff. I had a look at it once and I'm not sure if it is really necessary to do so. I'm tempted to bring it back to 1.4, because it looks a bit like they used it only because it is cool to use Java 5 idioms. (my 2 cents) Don't get me wrong. I'm not against progress, but I keep in mind that not all peoples are geeks, always willing to have the latest stuff. If you write a plug-in keep your customers in view. If you want to limit yourself go for the newer Java versions! Personally I'm running 1.6 because of the better performance, but I regularly test against older versions too. If I use 1.5+ in project (which I do) then I really mean it. Then I use annotations which can be done some magic with, using generics to full extent and I use the larger library! I do this in new projects (without legacy code) and belief me: the code looks quiet different compared to *JUMP code. *JUMP is legacy code. The development starts with 1.3 I guess. We have a lot of constraints which prevents us from refactoring it in the large. I would opt for a more Java 1.4 than 1.5 core. But this is a matter of decision that can change some day. Regards, Sascha Sunburned Surveyor schrieb: Should I avoid using 1.6 in my development for plug-ins and the core? The Sunburned Surveyor On 6/21/07, Paul Austin [EMAIL PROTECTED] wrote: Excellent, I want to use generics in my plug-ins to make lists more type safe. Cheers, Paul Stefan Steiniger wrote: at least 1.5 at least the nightly built is (necessarily) compiled with java 1.5 stefan Paul Austin wrote: Which Java version should we be developing plug-ins to. I notice that some of the modules in the core require 1.5 Paul - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Java version
SS, Sunburned Surveyor schrieb: [...] Sascha wrote: The original JUMP uses still 1.4 IIRC and I would tend to say this a wise idea if you want to reach customers which are not willing to install a newer JVM (for a number of serious reasons). What reasons would there be for avoiding the installation of a new JRE? Risk minimization e.g. Ever thought about the fact that *JUMP may not be the only running Java app on your machine? What if the other one is your business and/or mission critical app? What if this app works fine with 1.4 and has known quirks with 1.5? [1] What if *JUMP and this are coupled in some way? (Gulp!) I bet in such a situation you wouldn't dare to install a new JVM! P.S. - I believe UDig and some others actually install a JRE with their program. Not that I am a big fan of that idea. This has to do with the reason i stated above. With a given version that you have tested you can ensure certain things. Nonetheless it's bad practice... - Sascha [1] Browse a bit at http://bugs.sun.com to see what I mean. ;-) - 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] GPL and LGPL Compatibility
If only GPL and LGPL are involved then there is no problem. see: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses - Sascha Sunburned Surveyor schrieb: I was talking to Jody Garnett a little bit about a home for a converter or pair of converters that would allow developers to do the GeoTools JUMP and JUMP GeoTools Feature Model conversion. He said that there may be some issues since any code that I write will necessarily need to utilize JUMP code released under the GPL. This is an issue because GeoTools is released under the LGPL. I don't know as much about this area as I should, so I'm hoping to get some suggestions from this group. How might I be able to get code that works with JUMP code under the GPl to play nice with GeoTools code released under the LGPL? Is this even possible? Thanks for the suggestions. The Sunburned Surveyor - 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] GPL and LGPL Compatibility
Paul, note that 'commercial' is _not_ the opposite of 'free software'! 'Proprietary' or 'non free' is the opposite. - Sascha Paul Austin schrieb: The only problem would be if you used SS's new classes in a commercial application. Which in fact would be unlikely as they would not be allowed to use the JUMP code anyway because it is GPL. I think the rule is commercial apps can use LGPL libraries but not GPL ones. I took another approach for the same problem I added a FeatureFactory to my reader components and have a JumpFeatureFactory that will create features which implement both my DataObject interface and the Jump Feature interface. This way there is no conversion required between feature models. You just set the factory based on the type of feature instance you want. The reader uses this factory to create the instances. Paul - 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
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 features for the end users ... 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 that triggers a repaint any x ms. First of all let me state that we are not talking about 'A new ThreadQueue' any more. The problems we discussing now exist with the old and the new one. See below. My main goal in this thread was to bring on a new ThreadQueue. Are we through with this? If yes, I will commit it. I'm not sure that changing the repaint timer setting from 1000 to 400 affects performance significantly. My benchmarks show a 3% increase in render time for burlulc. I'm not sure if that will be true for all platforms and CPUs. There could be some advantage from my Dell's P4 hyper-threading here. I'll have to do more tests on a single CPU to be sure. I did drop the time to 40 ms and got a 22% increase. At that level, Jon's comment about too little happening each repaint rang true. Sorry Larry, setting the the value to 400ms does not solve the problem on my lower end machine. The flash is regularly omitted if I zoom to smaller scales. All the tweaking you are suggesting seems to scale with your horse power (only). A 400 ms repaint timer doesn't solve the problem, but it makes it bearable for zoom to selected. I can't speak to how this affects the printing plugins. For databases and WMSLayers, it isn't the solution. Exactly. And you may be supprised: there are people out there who want to print WMS layers too. Ask Jukka! Are the printing plugins working around this problem now by long delays or what? The Print/Layout plug-in offers an option to set a wait time for this kind of layers with a comment like Sorry dear user, we aren't capable to figure out how long it may take to print this layer. Try several value. Do some nested intervals. Do a little trial and error. IMHO this isn't very cool. Same for zooming. To avoid expensive data import into the Print/Layout plug-in we offer the opportunity to insert previews (screen shots) of the map. Later when the real print is done the data needs to be extracted from the GIS. This involves a zooming to a bookmarked position. Zooming is not reliable. So we have the same waiting options here with the same cheesy comment Sorry, dear user ... I can live with this. As I said a long time ago at the very beginning of this thread: I can explain this to customers, I'm able proof the quirks and I'm also able to show possible solutions. The real interesting question (to me) is: Is it possible in OpenJUMP to correct little design flaws like this? Even if we have to bend the original design a bit? I'll have a keen look at Landons pluggable renderer stuff ... I'm trying to assess the impact of not fixing this issue right now. I don't want to minimize the problem, but I see other more pressing issues of speed and usability that need my attention right now. I need to work on the speed of Task Loading, and I found a new issue today working with very large datasets. It takes a _very_ long time to delete 50,000 objects. I see big gains with minimal effort expended in these areas. This is fine to me and I appreciate this. I have other things for the 'big plot'(tm) in the pipe too (the improved WMS support e.g). I'm the last who wants to throttle you with unimportant things. :-) So Sascha, what is your other suggestion for a less radical solution? Larry, the modifications I'd suggested were very easy to implement. I removed the Timer in the RenderingManager, adjusted the Renderers and made the RenderingManager a RenderingMaster which is able to track the rendering. Under [1] you find the according src tree. I left out the docs/libs/dlls and so on. If one is interested look at Renderer, RenderingManager, ImageCachingRenderer, ImageCachingFeatureCollectionRenderer and ZoomToSelectedItemsPlugIn. Now the less radical solution: Start a new thread in ZoomToSelectedItemsPlugIn and let it sleep for 400ms before you do the flash. Something like this has to be done in all cases because the ThreadQueue tells you about the end of a rendering thread and not if the panel is ready for a flash. This has to do with repaint()/copyTo() stuff which has to be done afterwards and takes some (machine dependent) time too. regards, Sascha [1] http://intevation.de/~teichmann/openjump/openjump-src-renderer-mod.tar.bz2 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Hi SS, Sunburned Surveyor schrieb: [...] Stephan wrote: What about the binary-libs? I encountered broken libs at least under WFSPlugin/libs/*.jar. It seems they were not commited as binary in CVS. I didn't think that CVS could store binary files like SVN. Or at least I thought CVS couldn't version binary files like SVN. Perhaps this was the problem? At any rate, I don't think that this will prevent us from using the SVN repository for development now, though we should fix it at some point. (Any volunteers?) :] Binaries must be marked as binaries in CVS. I guess someone has forgotten to set the binary flag when the libs were checked in. Now they are messed. I can do so checksumming ... again. Stephan wrote: Is it possible to have the commit-emails sent to the mailing list as it was with CVS? I'm not sure about this one. I never noticed commit e-mails coming to this mailing list from the JPP CVS Repository. (Maybe I wasn't paying attention?) If this is something the developers would like I can look into it. I'm sure that there is a way to do it with SourceForge. I don't personally prefer these types of messages and I don't know that we need them if everyone is disciplined and uses the changelog text file. What do you guys think? Do we want to have SVN commit messages sent to the mailing list? Stephan is talking about an equivalent to the jump-pilot-cvslog list, not the jump-pilot-devel list. And yes, such a list is very useful to get on top with recent changes. Not everybody scans the ChangeLogs regularly. An e-mail notification would be nice. Stephan wrote: Asked that I think that the plugins should have its own trunk|tags|branches-tree like Paul suggested. I know it is a little more work, but separate releases of the plugins are then possible and more transparent. Please see my comments to Paul above. I don't really want to dictate structure to the plug-in developers. Don't you want it or don't you know how to do it? I think Paul's and Stephan's idea is worth thinking about. Regards, Sascha - 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
{
flash(geometries, panel);
} catch (NoninvertibleTransformException e) {};
}
});
This works great in SkyJUMP where I also used it to fix my refresh
timer and ZoomRealtime, however although it is better than the
Listener in OpenJump, it still occasionally flashes first and then
zooms. Clearly there is something wrong, but it is not in your
ThreadQueue code. I'll look some more tomorrow.
regards,
Larry
On 6/18/07, *Larry Becker* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
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,
Larry
On 6/18/07, Sascha L. Teichmann [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
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 printed before the display
is in the right 'mood' to display a flash. Result: no visible
flash or only a shortened variant.
Don't you have the same effects with the original one?
I have!
Register a println Listener yourself to the ThreadQueue
and be surprised how often it is called.
The zoom plug-in builds on this assumption the even more venturous
assumption that the zoom is done when there no more running
threads.
It does not take into account that the hole
repaint()/erase()/copyTo()
stuff also takes some time. The invokeLater() call does not make it
more predictable.
Let us compare the TQs:
1) Original TQ:
public void add(final Runnable runnable) {
queuedRunnables.add(new Runnable() {
public void run() {
try {
runnable.run();
} finally {
setRunningThreads(getRunningThreads() - 1);
processQueue();
}
}
});
processQueue();
}
private void setRunningThreads(int runningThreads) {
this.runningThreads = runningThreads;
if (runningThreads == 0) { fireAllRunningThreadsFinished(); }
}
The defaultRenderingThread has only one Thread running.
- runningThreads == 1 during try block of new Runnable.run().
setRunningThread() in the finally sets it to zero
- listeners get there kick.
This means that after each and every job the listeners get
kicked.
2) New TQ: (in worker thread's run())
for (;;) {
// unimportant part
try {
runnable.run();
}
catch (Exception e) {
e.printStackTrace();
}
boolean lastRunningThread;
synchronized (runningThreads) {
lastRunningThread = runningThreads[0] == 1;
}
if (lastRunningThread) {
fireAllRunningThreadsFinished();
}
}
The defaultRenderingThread has only one Thread running.
- runningThreads[0] == 1
after the try block lastRunningThread is set to true
if runningThreads[0] == 1. This is always fulfilled for
the defaultRenderingThread.
- listeners get there kick.
This means that after each and every job the listeners get
kicked.
= Same behavior for 1) and 2)
Maybe I bore you a bit by repeating it.
Regards,
Sascha
Larry Becker schrieb:
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]
mailto
Re: [JPP-Devel] Initial Phase of Subversion Migration
SS, [...] That is a good thing. It means that we don't have to mess with creating a new dump file. Sascha, will the script you provided create a SVN repository from the dump file Andreas provided. I guess I'm a little confused as to its purpose. [...] The script was mainly attached for documenting my work. Playing with local repositories has the advantage that you can check several things without the time penalty coming with SF. Sascha wrote: Therefore the mistake was being made later when importing the dump into SF's repository. The conversion process at SourceForge is pretty much a one button click process. I am wondering if I deleted something and then replaced it with an older version from somewhere. I'm not sure how I did this, but I've learned the hard way when everything else seems to be working the mistake made is my own. :] The web page SF provides reads like its simply a parameter collector for 'svnadmin load' plus some batching for queued job execution. I cannot see any magic in there and I've no idea what went wrong. Perhaps I'll try starting from scratch with the dump file that Andreas created. What a pain in the neck! I would give it one more try. But only one. If this one will fail too, we need to do some more intensive error analysis. Even if I doubt it sometimes computers are defined to be deterministic machines. - Sascha - 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
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 fires the
Listeners when the running threads went down to zero.
We can do the same when we're in the situation that we
are the last remaining thread with our job done.
In this case the number of running threads is
one but this measure wasn't reliable in the old
ThreadQueue too. So it doesn't matter.
But in difference to the original we keep the
worker thread alive afterwards instead of killing it.
Find attached a new version of the ThreadQueue that
implements this behavior.
regards,
Sascha
Larry Becker schrieb:
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 that can't be seen or measured.
How about 400 ms? That is about the average reaction time.
regards,
Larry Becker
/*
* The Unified Mapping Platform (JUMP) is an extensible, interactive GUI
* for visualizing and manipulating spatial features with geometry and attributes.
*
* Copyright (C) 2003 Vivid Solutions
* Copyright (C) 2007 Intevation GmbH
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Suite #1A
* 2328 Government Street
* Victoria BC V8T 5G5
* Canada
*
* (250)385-6040
* www.vividsolutions.com
*/
package com.vividsolutions.jump.workbench.ui.renderer;
import java.util.LinkedList;
import java.util.ArrayList;
/**
* This thread queue executes at maximum N Runnables in parallel
* were N is a given number of worker threads that should be used.
* If N threads are running and busy each further incoming
* Runnable is queued until one of the threads has finished its current job.
* If a worker thread becomes idle (no more job in the queue)
* it is hold alive for 5 seconds. If during this period of time
* no new Runnable is enqueued the worker thread dies.
*
* @author Sascha L. Teichmann ([EMAIL PROTECTED])
*/
public class ThreadQueue
{
/** The time a worker thread stays alive if idle */
public static final long WORKER_STAY_ALIVE_TIME = 5000L;
/**
* Worker thread. Fetches Runnable from the surrounding
* ThreadQueue instance.
*/
protected class Worker
extends Thread
{
public void run() {
try {
for (;;) {
Runnable runnable;
synchronized (queuedRunnables) {
if (queuedRunnables.isEmpty()) {
++waitingThreads;
try {
queuedRunnables.wait(WORKER_STAY_ALIVE_TIME);
}
catch (InterruptedException ie) {
}
finally {
--waitingThreads;
}
// if still empty - die!
if (queuedRunnables.isEmpty())
break;
}
if (disposed)
break;
runnable = (Runnable)queuedRunnables.remove();
} // synchronized queuedRunnables
try {
runnable.run();
}
catch (Exception e) {
e.printStackTrace();
}
// check if we are the last of the mohicans ...
boolean lastRunningThread;
synchronized (runningThreads) {
lastRunningThread = runningThreads[0] == 1;
}
if (lastRunningThread) {
fireAllRunningThreadsFinished();
}
} // for (;;)
}
finally { // guarantee that counter goes down
synchronized (runningThreads) {
--runningThreads[0];
}
}
}
} // class Worker
/**
* If the number of running threads goes down to zero
* implementations of this interface are able to be informed.
*/
public interface Listener {
void allRunningThreadsFinished();
} // interface Listener
/** Number of running threads */
protected int [] runningThreads = new int[1];
/** max. Number of threads running parallel */
protected int maxRunningThreads;
/** Number of threads that are currently idle */
protected int waitingThreads;
/** The queue of Runnables jobs waiting to be run */
protected LinkedList queuedRunnables;
/** Singals that the ThreadQueue is going to quit */
protected boolean disposed;
/** List
Re: [JPP-Devel] A new ThreadQueue
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 printed before the display
is in the right 'mood' to display a flash. Result: no visible
flash or only a shortened variant.
Don't you have the same effects with the original one?
I have!
Register a println Listener yourself to the ThreadQueue
and be surprised how often it is called.
The zoom plug-in builds on this assumption the even more venturous
assumption that the zoom is done when there no more running threads.
It does not take into account that the hole repaint()/erase()/copyTo()
stuff also takes some time. The invokeLater() call does not make it
more predictable.
Let us compare the TQs:
1) Original TQ:
public void add(final Runnable runnable) {
queuedRunnables.add(new Runnable() {
public void run() {
try {
runnable.run();
} finally {
setRunningThreads(getRunningThreads() - 1);
processQueue();
}
}
});
processQueue();
}
private void setRunningThreads(int runningThreads) {
this.runningThreads = runningThreads;
if (runningThreads == 0) { fireAllRunningThreadsFinished(); }
}
The defaultRenderingThread has only one Thread running.
- runningThreads == 1 during try block of new Runnable.run().
setRunningThread() in the finally sets it to zero
- listeners get there kick.
This means that after each and every job the listeners get kicked.
2) New TQ: (in worker thread's run())
for (;;) {
// unimportant part
try {
runnable.run();
}
catch (Exception e) {
e.printStackTrace();
}
boolean lastRunningThread;
synchronized (runningThreads) {
lastRunningThread = runningThreads[0] == 1;
}
if (lastRunningThread) {
fireAllRunningThreadsFinished();
}
}
The defaultRenderingThread has only one Thread running.
- runningThreads[0] == 1
after the try block lastRunningThread is set to true
if runningThreads[0] == 1. This is always fulfilled for
the defaultRenderingThread.
- listeners get there kick.
This means that after each and every job the listeners get kicked.
= Same behavior for 1) and 2)
Maybe I bore you a bit by repeating it.
Regards,
Sascha
Larry Becker schrieb:
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 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 fires the
Listeners when the running threads went down to zero.
We can do the same when we're in the situation that we
are the last remaining thread with our job done.
In this case the number of running threads is
one but this measure wasn't reliable in the old
ThreadQueue too. So it doesn't matter.
But in difference to the original we keep the
worker thread alive afterwards instead of killing it.
Find attached a new version of the ThreadQueue that
implements this behavior.
regards,
Sascha
Larry Becker schrieb:
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 that can't be seen or measured.
How about 400 ms? That is about the average reaction time.
regards,
Larry Becker
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists
Re: [JPP-Devel] Initial Phase of Subversion Migration
SS, I had a brief look at the ViewVC front end of the the subversion repository and now it looks pretty good. Have you started the conversion process again? - Sascha Sascha L. Teichmann schrieb: SS, [...] That is a good thing. It means that we don't have to mess with creating a new dump file. Sascha, will the script you provided create a SVN repository from the dump file Andreas provided. I guess I'm a little confused as to its purpose. [...] The script was mainly attached for documenting my work. Playing with local repositories has the advantage that you can check several things without the time penalty coming with SF. Sascha wrote: Therefore the mistake was being made later when importing the dump into SF's repository. The conversion process at SourceForge is pretty much a one button click process. I am wondering if I deleted something and then replaced it with an older version from somewhere. I'm not sure how I did this, but I've learned the hard way when everything else seems to be working the mistake made is my own. :] The web page SF provides reads like its simply a parameter collector for 'svnadmin load' plus some batching for queued job execution. I cannot see any magic in there and I've no idea what went wrong. Perhaps I'll try starting from scratch with the dump file that Andreas created. What a pain in the neck! I would give it one more try. But only one. If this one will fail too, we need to do some more intensive error analysis. Even if I doubt it sometimes computers are defined to be deterministic machines. - Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Initial Phase of Subversion Migration
Hi Landon, The ChangeLog friends are old, at the wrong place and not identical to the last one found in CVS. This do not provide confidence. Should I do some md5-summing all over the trees? Have you verified the identity of CVS and SVN before moving around things and changing the structure? BTW: Your proposed check-in message are too wordy. Call sign and date are simply redundant. They come with the check in. Action type does not provide any useful information and can also be reconstruct from the SVN history. All what matters is the description. And prefix a description with Description: is a bit redundant too. When I use the web front end of SVN I will only see trimmed things like Call Sign: The Sunburned Surveyor Action Type: Move Date: 2007-06-13 ... in the column of Last log entry. This relevant part is missing. Regards, Sascha Sunburned Surveyor schrieb: I believe the tentative migration from the JPP CVS to the JPP SVN is complete. It took me a while to accomplish what we wanted, but I think I've finally got it over the course of the last two days. (I had to use both RapidSVN and Eclipse to get things set up properly.) There is now a stable branch of OpenJUMP's code base found in the /branches/openjump_stable_1_2 directory of the JPP Subversion Repository. Development code can now go into the /trunk/src directory of the Subversion Repository. I'll start the weekly builds this week. I think I'll end up doing one of the stable branch and one of the development trunk. Let me know if you guys have any questions. If something still isn't correct with the SVN I will try to fix it. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Initial Phase of Subversion Migration
SS, if I do the following: - fetch a clean anonymous SVN check-out - generate md5sums for the files - fetch a clean anonymous CVS check-out - run a md5sum check against the generated one I receive following result: md5sum: WARNING: 3 of 1421 listed files could not be read md5sum: WARNING: 104 of 1418 computed checksums did NOT match Running 'diff' against some selected give real differences. Take ShapefileWriter.java as an example. IMHO this is a very strong indicator that something went wrong. I attach a script how I did it. I've run the lines interactively, so no guarantee that it works in total. Maybe I've done something wrong. In this case shame on me ... Regards, Sascha Sunburned Surveyor schrieb: Sascha, You wrote: The ChangeLog friends are old, at the wrong place and not identical to the last one found in CVS. I am working from the SVN dump file that Andreas provided me, so I am surprised to hear that the logs are out of date. Has there been more commits to the CVS since I started my migration? At any rate, I think this can easily be fixed. I will have to download the logs currently in the CVS and place them in my working copy of the SVN repository. They should be submitted when I do my next commit. I will also check the location of the logs. It's possible they got misplaced when I was trying to implement the structure needed for the stable branch. You wrote: This do not provide confidence. Yup. This is definitely not going as smoothly as I had hoped it would. Feel free to chip and help straighten things out. :] You wrote: BTW: Your proposed check-in message are too wordy. Call sign and date are simply redundant. They come with the check in. Action type does not provide any useful information and can also be reconstruct from the SVN history. All what matters is the description. And prefix a description with Description: is a bit redundant too. When I use the web front end of SVN I will only see trimmed things like Call Sign: The Sunburned Surveyor Action Type: Move Date: 2007-06-13 ... in the column of Last log entry. This relevant part is missing. These are all good comments. I did not realize that the other information was already included in the log. It sounds like all we really need to include in the commit message is a description. Let's go with that policy, and I will also change it for my usage of the SVN at the SurveyOS Project. The Sunburned Surveyor svn-cvs.sh Description: Bourne shell script - 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] Initial Phase of Subversion Migration
Hi Michaël, ShapefileWriter was only one example, TaskFrame is another. This one was last modified on 2007-06-03 and we have an older version in SVN ... Because ChangeLog, Changes.txt and TODO.txt are in the version of 2007-06-02 in subversion I would reckon that we lost all changes after 2007-06-02. It would be of interest how Andreas generated the svndump file. I would have done it with something like: $ rsync -avz rsync://jump-pilot.cvs.sourceforge.net/cvsroot/jump-pilot/* jump-pilot-cvsbackup $ cd jump-pilot-cvsbackup $ cvs2svn --dump-only --dumpfile=svndump . Regards, Sascha Michaël Michaud schrieb: Hi SS, Sascha, Paul... Thank you to do all this hard work for migration. Just as an indication, ShapefileWriter is one of the last modification I did on the CVS (2007-06-12) Promise : I make no more change until the migration is completely finished ! Michaël Sascha L. Teichmann a écrit : SS, if I do the following: - fetch a clean anonymous SVN check-out - generate md5sums for the files - fetch a clean anonymous CVS check-out - run a md5sum check against the generated one I receive following result: md5sum: WARNING: 3 of 1421 listed files could not be read md5sum: WARNING: 104 of 1418 computed checksums did NOT match Running 'diff' against some selected give real differences. Take ShapefileWriter.java as an example. IMHO this is a very strong indicator that something went wrong. I attach a script how I did it. I've run the lines interactively, so no guarantee that it works in total. Maybe I've done something wrong. In this case shame on me ... Regards, Sascha Sunburned Surveyor schrieb: Sascha, You wrote: The ChangeLog friends are old, at the wrong place and not identical to the last one found in CVS. I am working from the SVN dump file that Andreas provided me, so I am surprised to hear that the logs are out of date. Has there been more commits to the CVS since I started my migration? At any rate, I think this can easily be fixed. I will have to download the logs currently in the CVS and place them in my working copy of the SVN repository. They should be submitted when I do my next commit. I will also check the location of the logs. It's possible they got misplaced when I was trying to implement the structure needed for the stable branch. You wrote: This do not provide confidence. Yup. This is definitely not going as smoothly as I had hoped it would. Feel free to chip and help straighten things out. :] You wrote: BTW: Your proposed check-in message are too wordy. Call sign and date are simply redundant. They come with the check in. Action type does not provide any useful information and can also be reconstruct from the SVN history. All what matters is the description. And prefix a description with Description: is a bit redundant too. When I use the web front end of SVN I will only see trimmed things like Call Sign: The Sunburned Surveyor Action Type: Move Date: 2007-06-13 ... in the column of Last log entry. This relevant part is missing. These are all good comments. I did not realize that the other information was already included in the log. It sounds like all we really need to include in the commit message is a description. Let's go with that policy, and I will also change it for my usage of the SVN at the SurveyOS Project. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] openjump icon
Nice idea, Pedro! :-) Maybe a SVG would be nice, too? I've attached a quick potrace'd version. It may need some work. Kind regards, Sascha Pedro Doria Meunier schrieb: Hi guys, Since the OJ distro for Linux doesn't contain an icon, here's a png image to be included in the tar... ;-) (perhaps in zip_root/icon ?) This way users can put a relevant icon on the desktop for OJ. png: 48x31 32bpp - 1.862 bytes Hope you enjoy it! Kind regards, Pedro Doria Meunier. - 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 inline: openjump.svg- 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] Initial Phase of Subversion Migration
Hi Andreas, this sounds all okay to me. I'm currently downloading your dump file and I will have a look at it tomorrow. It its possibly a good idea to set up a local SVN repository and evaluate if this suffers from data loss too. If this is the case something is wrong with the dumpfile and a new one has to be created. If this is not the case then maybe something went wrong at SF's conversion. Regards, Sascha Andreas Schmitz schrieb: Sascha L. Teichmann wrote: Hello, It would be of interest how Andreas generated the svndump file. I would have done it with something like: $ rsync -avz rsync://jump-pilot.cvs.sourceforge.net/cvsroot/jump-pilot/* jump-pilot-cvsbackup $ cd jump-pilot-cvsbackup $ cvs2svn --dump-only --dumpfile=svndump . I used rsync -av (without the z) and also deleted the CVSROOT directory tree before invoking cvs2svn. I also did not use --dump-only (it seems not to exist as an option in my manpage). I used version 1.5.0. If it helps you, the dumpfile still resides in /home/groups/j/ju/jump-pilot on shell.sf.net. As to the problems we're having, I have no clue how some of the files could have an old version. Best regards, Andreas - 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] Initial Phase of Subversion Migration
Okay, I've created a local SVN repository [1], loaded the dump and checked out the trunk. All was pretty fine. Plug-ins were there, and the only md5sum mismatches come from tag substitution, but this alright. Ergo: Andreas dump file seems to be fine. Therefore the mistake was being made later when importing the dump into SF's repository. Best, Sascha [1] see attached script - I'd run the commands individually so no guarantee that the script works. Sascha L. Teichmann schrieb: Hi Andreas, this sounds all okay to me. I'm currently downloading your dump file and I will have a look at it tomorrow. It its possibly a good idea to set up a local SVN repository and evaluate if this suffers from data loss too. If this is the case something is wrong with the dumpfile and a new one has to be created. If this is not the case then maybe something went wrong at SF's conversion. Regards, Sascha Andreas Schmitz schrieb: Sascha L. Teichmann wrote: Hello, It would be of interest how Andreas generated the svndump file. I would have done it with something like: $ rsync -avz rsync://jump-pilot.cvs.sourceforge.net/cvsroot/jump-pilot/* jump-pilot-cvsbackup $ cd jump-pilot-cvsbackup $ cvs2svn --dump-only --dumpfile=svndump . I used rsync -av (without the z) and also deleted the CVSROOT directory tree before invoking cvs2svn. I also did not use --dump-only (it seems not to exist as an option in my manpage). I used version 1.5.0. If it helps you, the dumpfile still resides in /home/groups/j/ju/jump-pilot on shell.sf.net. As to the problems we're having, I have no clue how some of the files could have an old version. Best regards, Andreas - 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 load-svn-checkout.sh Description: Bourne shell script - 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
current job.
* If a worker thread becomes idle (no more job in the queue)
* it is hold alive for 5 seconds. If during this period of time
* no new Runnable is enqueued the worker thread dies.
*
* @author Sascha L. Teichmann ([EMAIL PROTECTED])
*/
public class ThreadQueue
{
/** The time a worker thread stays alive if idle */
public static final long WORKER_STAY_ALIVE_TIME = 5000L;
/**
* Worker thread. Fetches Runnable from the surrounding
* ThreadQueue instance.
*/
protected class Worker
extends Thread
{
public void run() {
try {
for (;;) {
Runnable runnable;
synchronized (queuedRunnables) {
if (queuedRunnables.isEmpty()) {
++waitingThreads;
try {
queuedRunnables.wait(WORKER_STAY_ALIVE_TIME);
}
catch (InterruptedException ie) {
}
finally {
--waitingThreads;
}
// if still empty - die!
if (queuedRunnables.isEmpty())
break;
}
if (disposed)
break;
runnable = (Runnable)queuedRunnables.remove();
} // synchronized queuedRunnables
try {
runnable.run();
}
catch (Exception e) {
e.printStackTrace();
}
} // for (;;)
}
finally { // guarantee that counter goes down
boolean allRunningThreadsFinished;
synchronized (runningThreads) {
allRunningThreadsFinished = --runningThreads[0] == 0;
}
if (allRunningThreadsFinished)
fireAllRunningThreadsFinished();
}
}
} // class Worker
/**
* If the number of running threads goes down to zero
* implementations of this interface are able to be informed.
*/
public interface Listener {
void allRunningThreadsFinished();
} // interface Listener
/** Number of running threads */
protected int [] runningThreads = new int[1];
/** max. Number of threads running parallel */
protected int maxRunningThreads;
/** Number of threads that are currently idle */
protected int waitingThreads;
/** The queue of Runnables jobs waiting to be run */
protected LinkedList queuedRunnables;
/** Singals that the ThreadQueue is going to quit */
protected boolean disposed;
/** List of Listeners */
protected ArrayList listeners = new ArrayList();
/**
* Creates a ThreadQueue with one worker thread.
*/
public ThreadQueue() {
this(1);
}
/** Creates a ThreadQueue with a given number of worker threads.
* @param maxRunningThreads the max. number of threads to be run parallel.
*/
public ThreadQueue(int maxRunningThreads) {
this.maxRunningThreads = Math.max(1, maxRunningThreads);
queuedRunnables = new LinkedList();
}
/**
* Adds a Listener to this ThreadQueue.
* @param listener the listener to add.
*/
public synchronized void add(Listener listener) {
if (listener != null)
listeners.add(listener);
}
/**
* Removes a Listener from this ThreadQueue.
* @param listener the listener to be removed.
*/
public synchronized void remove(Listener listener) {
if (listener != null)
listeners.remove(listener);
}
/**
* Informs Listeners of the fact that the number of running threads
* went to zero.
*/
protected void fireAllRunningThreadsFinished() {
ArrayList copy;
synchronized (this) { copy = new ArrayList(listeners); }
for (int i = copy.size()-1; i = 0; --i)
((Listener)copy.get(i)).allRunningThreadsFinished();
}
/**
* The number of currently running worker threads.
* @return number of currently running worker threads.
*/
public int runningThreads() {
synchronized (runningThreads) {
return runningThreads[0];
}
}
/**
* The number of currently running worker threads.
* Alias for runningThreads()
* @return number of currently running worker threads.
*/
public int getRunningThreads() {
return runningThreads();
}
/**
* The number of currently waiting Runnables.
* @return number of currently waiting Runnables.
*/
public int waitingRunnables() {
synchronized (runningThreads) {
return queuedRunnables.size();
}
}
/**
* The number of currently idle worker threads.
* @return number of currently idle worker threads.
*/
public int waitingThreads() {
synchronized (queuedRunnables) {
return waitingThreads;
}
}
/**
* Adds a Runnables to the queue. It will be run in one
* of the worker threads.
* @param runnable The Runnables to add
*/
public void add(Runnable runnable) {
int waiting;
synchronized (queuedRunnables) {
if (disposed)
return;
waiting = waitingThreads;
queuedRunnables.add(runnable);
queuedRunnables.notify();
} // synchronized (queuedRunnables)
synchronized (runningThreads) {
// if waitingThreads == 1 then
// the queuedRunnables.notify() should have waked it up.
if (waitingThreads 2 runningThreads[0] maxRunningThreads) {
++runningThreads[0];
Worker w = new Worker();
w.setDaemon(true);
w.start();
}
} // synchronized (runningThreads)
}
/**
* Empties the queue
Re: [JPP-Devel] A new ThreadQueue
In core the
com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn
uses the ThreadQueue.Listener interface. But the code looks like it can
cope with the 'slightly' shifted semantic.
I would vote for stick a @deprecated tag (+ some explanations)
to the respective methods and to the interface because code
that uses these mechanisms is possibly not aware of the
sophisticated difference between 'no running threads left'
and 'all jobs done'.
- Sascha
Larry Becker schrieb:
Hi Sascha,
Adding a 'wakeup' Runnable works great and is easier than using the
listener anyway.
By the way, I couldn't find any other code using the Listener
interface, but I suppose there could be a Plug-in somewhere that does.
We should probably leave it out anyway since if we are leaving it in
for compatibility, it should actually be compatible. The easiest way
to find out if it is really needed by anyone but me might be to leave
it out and see if it breaks anyone's compile. The same applies to
getRunningThreads since it doesn't behave exactly like it did before
either.
Anyway, thanks for the help. I'm able to determine the end of
rendering much more accurately now.
regards,
Larry Becker
On 6/15/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hello Larry,
the version of the ThreadQueue is a bit outdated.
The version you have has no getRunningThreads() method.
This is need for compatibility. And there was a bug in
remove(Listener) which is fixed by now.
I attach the current ThreadQueue.
Now to your problem:
The Listeners are in for compatibility and you are right
they get there kick when the WORKER_STAY_ALIVE_TIME has
expired. But once again: These Listeners _do_ _not_ help
you! You want to know when the last job has ended, not
when there are no more running Threads. We discussed this
already.
I would suggest the following solution on your side
to archive the desired effect:
code
Graphics2D destination = ... // from outer space
LayerViewPanel layerViewPanel = ... // from outer space
RenderingManager renderingManager =
layerViewPanel.getRenderingManager();
ThreadQueue defaultThreadQueue =
renderingManager.getDefaultRendererThreadQueue();
// add all the Renderer Runnables to the ThreadQueue
renderingManager.renderAll();
final boolean [] locked = { true };
// because defaultThreadQueue does its jobs
// one after each other append a 'wakeup' Runnable ...
defaultThreadQueue.add(new Runnable() {
public void run() {
synchronized (locked) {
locked[0] = false;
locked.notify();
}
}
});
try {
synchronized (locked) {
// you could simply write
// while (locked[0]) locked.wait();
// but following is more defensive
int count = 0;
while (locked[0] count++ 10)
locked.wait(1L);
}
}
catch (InterruptedException ie) {
}
renderingManager.copyTo(destination);
/code
But as I said earlier, this only works on
the defaultRenderingThreadQueue and therefore
its only an interim solution. The
WMS/DB ThreadQueue is private and a true
parallel ThreadQueue.
My goal is to add a renderAllSynchronized()
to RenderingManager that used the above
Runnable/unlock trick. The secret WMS/DB
will be eliminated (or better the default one
and the WMS/DB ThreadQueue will become the
default). This is doable with the
RunnableArrayList class I posted a while
ago, which simulates the single thread
default ThreadQueue. But one step after
the other ...
Regards, Sascha
Larry Becker schrieb:
Sascha,
I have reached a point where I need some help with the new
ThreadQueue implementation. I have modified my code that calls
getRunningThreads to use the Listener with the
allRunningThreadsFinished method instead. This was much cleaner and
worked fine until I replaced ThreadQueue with your version. The
problem I seem to be having is that the method doesn't fire until
after the 5 second WORKER_STAY_ALIVE_TIME has expired. Can you
explain what I should be doing or modify the code so that it fires
when there are no more jobs waiting?
I have attached the version of ThreadQueue.java that I have been using
in case it is outdated.
thanks,
Larry Becker
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2
Re: [JPP-Devel] A new ThreadQueue
Not if you want to do thread pooling.
The real problem: How can I get a notification
when a zoom is done?
The ZoomToSelectedItemsPlugIn ThreadQueue code looks
like a workaround due to lack of a real possibility
to get informed when the zoom is done.
I will have a look at this problem.
regards,
Sascha
Larry Becker schrieb:
I cut the WORKER_STAY_ALIVE_TIME to 50 ms and the flash now works. 50
ms is an eternity in CPU time anyway.
regards,
Larry
On 6/15/07, Larry Becker [EMAIL PROTECTED] wrote:
Thanks for finding that Listener use in ZoomToSelectedItemsPlugIn. I
tried it and it doesn't flash anymore.
regards,
Larry
On 6/15/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
In core the
com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn
uses the ThreadQueue.Listener interface. But the code looks like it can
cope with the 'slightly' shifted semantic.
I would vote for stick a @deprecated tag (+ some explanations)
to the respective methods and to the interface because code
that uses these mechanisms is possibly not aware of the
sophisticated difference between 'no running threads left'
and 'all jobs done'.
- Sascha
Larry Becker schrieb:
Hi Sascha,
Adding a 'wakeup' Runnable works great and is easier than using the
listener anyway.
By the way, I couldn't find any other code using the Listener
interface, but I suppose there could be a Plug-in somewhere that does.
We should probably leave it out anyway since if we are leaving it in
for compatibility, it should actually be compatible. The easiest way
to find out if it is really needed by anyone but me might be to leave
it out and see if it breaks anyone's compile. The same applies to
getRunningThreads since it doesn't behave exactly like it did before
either.
Anyway, thanks for the help. I'm able to determine the end of
rendering much more accurately now.
regards,
Larry Becker
On 6/15/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hello Larry,
the version of the ThreadQueue is a bit outdated.
The version you have has no getRunningThreads() method.
This is need for compatibility. And there was a bug in
remove(Listener) which is fixed by now.
I attach the current ThreadQueue.
Now to your problem:
The Listeners are in for compatibility and you are right
they get there kick when the WORKER_STAY_ALIVE_TIME has
expired. But once again: These Listeners _do_ _not_ help
you! You want to know when the last job has ended, not
when there are no more running Threads. We discussed this
already.
I would suggest the following solution on your side
to archive the desired effect:
code
Graphics2D destination = ... // from outer space
LayerViewPanel layerViewPanel = ... // from outer space
RenderingManager renderingManager =
layerViewPanel.getRenderingManager();
ThreadQueue defaultThreadQueue =
renderingManager.getDefaultRendererThreadQueue();
// add all the Renderer Runnables to the ThreadQueue
renderingManager.renderAll();
final boolean [] locked = { true };
// because defaultThreadQueue does its jobs
// one after each other append a 'wakeup' Runnable ...
defaultThreadQueue.add(new Runnable() {
public void run() {
synchronized (locked) {
locked[0] = false;
locked.notify();
}
}
});
try {
synchronized (locked) {
// you could simply write
// while (locked[0]) locked.wait();
// but following is more defensive
int count = 0;
while (locked[0] count++ 10)
locked.wait(1L);
}
}
catch (InterruptedException ie) {
}
renderingManager.copyTo(destination);
/code
But as I said earlier, this only works on
the defaultRenderingThreadQueue and therefore
its only an interim solution. The
WMS/DB ThreadQueue is private and a true
parallel ThreadQueue.
My goal is to add a renderAllSynchronized()
to RenderingManager that used the above
Runnable/unlock trick. The secret WMS/DB
will be eliminated (or better the default one
and the WMS/DB ThreadQueue will become the
default). This is doable with the
RunnableArrayList class I posted a while
ago, which simulates the single thread
default ThreadQueue. But one step after
the other ...
Regards, Sascha
Larry Becker schrieb:
Sascha,
I have reached a point where I need some help with the new
ThreadQueue implementation. I have modified my code that calls
getRunningThreads to use the Listener with the
allRunningThreadsFinished method instead. This was much cleaner and
worked fine until I replaced ThreadQueue with your version. The
problem I seem to be having is that the method doesn't fire until
after the 5 second WORKER_STAY_ALIVE_TIME has expired. Can you
explain what I should be doing or modify the code so that it fires
when there are no more jobs waiting?
I have attached the version of ThreadQueue.java that I have been using
in case it is outdated.
thanks,
Larry Becker
Re: [JPP-Devel] Fwd: Update on JPP Subversion Migration
Hi! What about the ChangeLog, Changes.txt and TODO.txt? I cannot find them in the SVN trunk. Regards, Sascha Sunburned Surveyor schrieb: I'm afraid I was already well into the process of setting up the SVN when I read the helpful e-mails in this thread. :[ I have made a stab at setting up the SVN for OpenJUMP at the JPP, and it *may* be ready for use. I made a trunk and branches folders under the openjump folder. I then created a branch of trunk in the branches/stable folder. This included the scripts, installers, etc., not just the trunk/src folder. This will allow us to version all elements of the release, not just the source code. I can change this if it is not acceptable. I also see everyone has SVN access. Can someone check my work on the SVN before we decide to go live with it. It is totally possible that I have royally messed things up. The Sunburned Surveyor P.S. - When we do go live changes to OpenJUMP should go in the trunk. After they have been approved (however that works) we can move them to the stable branch. P.S.S. - Might I suggest that we adopt a suggested format for commit comments? I lined out some really basic guidelines for the SurveyOS Project Subversion Repository. I'm not saying we should require developers follow something similar, just that we suggest they do. http://surveyoswiki.pbwiki.com/SurveyOS+Subversion+Repository+Usage+Guidelines (I know that having a simple commit log format could help if we wantd to use some scripts or parsing tools of the SVN logs in the future. At least that is what I read in one of my SVN books.) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Fwd: Update on JPP Subversion Migration
Hi Landon! I had a closer look now at the SVN stuff you've set up. Losing the CVS history is bad. You should really start over. See it as a first learning attempt. :-) - Sascha Sunburned Surveyor schrieb: Stefan, Thanks for the links. You wrote: but a side effect may be that the new structure would be the old one - if we can't do changes after migration One nice thing about SVN is that it is much easier to make structure changes. I will convert the existing CVS repository and then use the trunk and branches/trunk structure for the core unless someone has a better way to lay things out. The Sunburned Surveyor On 6/13/07, Stefan Steiniger [EMAIL PROTECTED] wrote: Landon, have you seen this: https://sourceforge.net/project/admin/svn_migration.php?group_id=118054 and the link from that side to the doc: https://sourceforge.net/docs/E09#import but a side effect may be that the new structure would be the old one - if we can't do changes after migration stefan btw. i have been logged in, to get this pages Sunburned Surveyor schrieb: I probably missed them. I will add them. SS On 6/13/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote: Hi! What about the ChangeLog, Changes.txt and TODO.txt? I cannot find them in the SVN trunk. Regards, Sascha Sunburned Surveyor schrieb: I'm afraid I was already well into the process of setting up the SVN when I read the helpful e-mails in this thread. :[ I have made a stab at setting up the SVN for OpenJUMP at the JPP, and it *may* be ready for use. I made a trunk and branches folders under the openjump folder. I then created a branch of trunk in the branches/stable folder. This included the scripts, installers, etc., not just the trunk/src folder. This will allow us to version all elements of the release, not just the source code. I can change this if it is not acceptable. I also see everyone has SVN access. Can someone check my work on the SVN before we decide to go live with it. It is totally possible that I have royally messed things up. The Sunburned Surveyor P.S. - When we do go live changes to OpenJUMP should go in the trunk. After they have been approved (however that works) we can move them to the stable branch. P.S.S. - Might I suggest that we adopt a suggested format for commit comments? I lined out some really basic guidelines for the SurveyOS Project Subversion Repository. I'm not saying we should require developers follow something similar, just that we suggest they do. http://surveyoswiki.pbwiki.com/SurveyOS+Subversion+Repository+Usage+Guidelines (I know that having a simple commit log format could help if we wantd to use some scripts or parsing tools of the SVN logs in the future. At least that is what I read in one of my SVN books.) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net
Re: [JPP-Devel] About Openjump SaveImageasSVG
Hi Guiseppe! Which version of OpenJUMP do you use? 1.2b? We've integrated a tweak to OpenJUMP (Viewport.setJava2DConverter()) a while ago to make it possible to have accurate vertices. The Print/Layout plug-in uses this mechanism and so the problem should _not_ appear if you use it with OpenJUMP 1.2b (nightly build)! @stefan: We should apply this improvement to SaveSVG, too. It would be nice if you give a bit more feedback so we can have a look at it. Kind regards, Sascha Stefan Steiniger schrieb: Hei Guiseppe, the problem comes from the screen resolution. The points/objects are distorted to enable a faster rendering. For the things you want, one needs a specific (new) export tool that does not depend on the screen resolution. furthermore there is another limit in the tool which is probably also a reason for the fact that your symbols are not shown. I introduced a number of features per layer limit (i think it is either 1000 or 5000 features per layer). This limit has been set to avoid that too large svg files are written, that can hardly be handled by drawing software. btw. i am not sure about a particular solution to your problem. Of course we would need to write a new renderer and export tool.. but this takes time. Btw. have you tried the other print plugin from Cadplan? (see openjump wiki) stefan Giuseppe Aruta schrieb: Hi Stephan, I am an Openjump user, I found very usefull your tool Save Image as SVG which is included in the new versions of the software. I tried to use Openjump to make geological maps on very large format (A0 and A1). Beeing the maps very large I usualy export them to SVGat the maximun scale. By the time that I saved those maps in SVG I discovered that the tool SVG can't export very small siymbols to their right shape (ex. 5 mm in a A0 map -1000x1414 mm) , but only to simple unregular polygons. I discover this problem also on the PrintLayout Save to SVG tool (the new version 1.0.1). Is this a limit of the SVG java library? Do you think it is possible to modify the tool in order to have a better SVG layout? Thanks you for your replay. Giuseppe Aruta Dipertimento di Scienze della Terra Università G. La Pira - Firenze - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] About Openjump SaveImageasSVG
Stefan, If you like I can apply some of the Print/Layout improvements to SaveImageAsSVGPlugIn. Rounded/truncated are one problem. Have you ever tried to save a SVG via SaveImageAsSVGPlugIn with (WKT) fill patterns on the map enabled? By now the fill patterns get lost or are replaced by a simple fill color. I can fix this, too. - Sascha Stefan Steiniger schrieb: Hei Sascha it is just one file and very very simple code (compared to your plugin): org.openjump.core.ui.plugin.file.SaveImageAsSVGPlugIn i did not even make it by myself.. i just merged some stuff by two different people stefan Sascha L. Teichmann schrieb: Hi Guiseppe! Which version of OpenJUMP do you use? 1.2b? We've integrated a tweak to OpenJUMP (Viewport.setJava2DConverter()) a while ago to make it possible to have accurate vertices. The Print/Layout plug-in uses this mechanism and so the problem should _not_ appear if you use it with OpenJUMP 1.2b (nightly build)! @stefan: We should apply this improvement to SaveSVG, too. It would be nice if you give a bit more feedback so we can have a look at it. Kind regards, Sascha Stefan Steiniger schrieb: Hei Guiseppe, the problem comes from the screen resolution. The points/objects are distorted to enable a faster rendering. For the things you want, one needs a specific (new) export tool that does not depend on the screen resolution. furthermore there is another limit in the tool which is probably also a reason for the fact that your symbols are not shown. I introduced a number of features per layer limit (i think it is either 1000 or 5000 features per layer). This limit has been set to avoid that too large svg files are written, that can hardly be handled by drawing software. btw. i am not sure about a particular solution to your problem. Of course we would need to write a new renderer and export tool.. but this takes time. Btw. have you tried the other print plugin from Cadplan? (see openjump wiki) stefan Giuseppe Aruta schrieb: Hi Stephan, I am an Openjump user, I found very usefull your tool Save Image as SVG which is included in the new versions of the software. I tried to use Openjump to make geological maps on very large format (A0 and A1). Beeing the maps very large I usualy export them to SVGat the maximun scale. By the time that I saved those maps in SVG I discovered that the tool SVG can't export very small siymbols to their right shape (ex. 5 mm in a A0 map -1000x1414 mm) , but only to simple unregular polygons. I discover this problem also on the PrintLayout Save to SVG tool (the new version 1.0.1). Is this a limit of the SVG java library? Do you think it is possible to modify the tool in order to have a better SVG layout? Thanks you for your replay. Giuseppe Aruta Dipertimento di Scienze della Terra Università G. La Pira - Firenze - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - 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] new files changelog, changes and todo on CVS
Hi together, I've created a sample ChangeLog [1] for with cvs2cl.pl for a fresh anonymous OpenJUMP CVS checkout. Please, have a look at it. When committing the BasicStyle patch I would like to add this for completeness to the src/ChangeLog. After this I recommend to maintain it manually. the call of cvs2cl.pl was: cvs2cl.pl --no-times -U emails.txt --show-dead --utc emails.txt is a map of email addresses I took from the JPP list. Spammmers already have these. Any, comments? - Sascha [1] http://intevation.de/~teichmann/printlayout/ChangeLog Stefan Steiniger schrieb: Salut Michael (i currently cant follow the list - to much is going on) Michaël Michaud schrieb: Hi, Thanks Stefan, Is there a way to use sourceforge cvs log to help completing the changelog file you just added ? i hope sascha's answer was sufficient.. i have not used it yet and did look only on the wfs and printplugin files for an example About the todo list, we may have to choose a central place. There are some todo lists on the wiki, there is the sourceforge feature request, the sourceforge bug report and now here... What others think ? i think the todo list in src folder is our personal (devel) thing and we shoudl also add here the improtant bugs that we receive at sourceforge. I also aggree with Sascha that it is somehow important not to rely on the wiki or webpages - thats rather for the publicity. Priority from now on should be on the comments in the new files (because i also have a personal todo list on my laptop related to ojump - which i can now move :o) bon nuit stefan Michaël Sunburned Surveyor a écrit : Thanks for taking care of this Stefan. Hopefully Sascha approves! SS On 6/2/07, Stefan Steiniger [EMAIL PROTECTED] wrote: btw. to check the files out in eclipse I used: - cvs repository explorer view - selected the src folder - chosed checkout as... from the mouse menu - disabled the subfolder checkbox - selected check out into existing project - i chosed my openjump project (but i could not remove the folder name src, thus the change log files will be in that project sub-folder - but a renaming to changelog should be possible) stefan Stefan Steiniger schrieb: Hei Guys, i added to the cvs module openjump\src\ three log files. Please check them out to enable a better logging of changes. I hope it is what Sascha expected? stefan PS: i dont know why my eclipse now wants to update the complete openjump\src tree. I hope it is only a problem with my machine and not yours as well. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] new files changelog, changes and todo on CVS
BTW: Why do you hide ChangeLog Co. in the src folder? Nice place to be overseen. One level up it would be more visual. But I can live with the current place. - Sascha Stefan Steiniger schrieb: that's pretty cool :) Sascha L. Teichmann schrieb: Hi together, I've created a sample ChangeLog [1] for with cvs2cl.pl for a fresh anonymous OpenJUMP CVS checkout. Please, have a look at it. When committing the BasicStyle patch I would like to add this for completeness to the src/ChangeLog. After this I recommend to maintain it manually. the call of cvs2cl.pl was: cvs2cl.pl --no-times -U emails.txt --show-dead --utc emails.txt is a map of email addresses I took from the JPP list. Spammmers already have these. Any, comments? - Sascha [1] http://intevation.de/~teichmann/printlayout/ChangeLog Stefan Steiniger schrieb: Salut Michael (i currently cant follow the list - to much is going on) Michaël Michaud schrieb: Hi, Thanks Stefan, Is there a way to use sourceforge cvs log to help completing the changelog file you just added ? i hope sascha's answer was sufficient.. i have not used it yet and did look only on the wfs and printplugin files for an example About the todo list, we may have to choose a central place. There are some todo lists on the wiki, there is the sourceforge feature request, the sourceforge bug report and now here... What others think ? i think the todo list in src folder is our personal (devel) thing and we shoudl also add here the improtant bugs that we receive at sourceforge. I also aggree with Sascha that it is somehow important not to rely on the wiki or webpages - thats rather for the publicity. Priority from now on should be on the comments in the new files (because i also have a personal todo list on my laptop related to ojump - which i can now move :o) bon nuit stefan Michaël Sunburned Surveyor a écrit : Thanks for taking care of this Stefan. Hopefully Sascha approves! SS On 6/2/07, Stefan Steiniger [EMAIL PROTECTED] wrote: btw. to check the files out in eclipse I used: - cvs repository explorer view - selected the src folder - chosed checkout as... from the mouse menu - disabled the subfolder checkbox - selected check out into existing project - i chosed my openjump project (but i could not remove the folder name src, thus the change log files will be in that project sub-folder - but a renaming to changelog should be possible) stefan Stefan Steiniger schrieb: Hei Guys, i added to the cvs module openjump\src\ three log files. Please check them out to enable a better logging of changes. I hope it is what Sascha expected? stefan PS: i dont know why my eclipse now wants to update the complete openjump\src tree. I hope it is only a problem with my machine and not yours as well. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits
Re: [JPP-Devel] new files changelog, changes and todo on CVS
done. Stefan Steiniger schrieb: ok, so lets move (Sascha could do that if he commits) stefan Stephan Holl wrote: Hello Stefan, Stefan Steiniger [EMAIL PROTECTED], [20070606 - 11:07:45] if you wish, you can change it. I thought it belongs rather to the src, and not to all the other etc stuff. I wouls vote to include it in the top-folder so that we can also keep track of changes of other folders like lib/, etc/, docs/... Best Stephan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Expensive construction of BasicStyle objects.
Hi together! I was wondering why it takes so long to enable Colour Theming when working with layers with a higher number of features. If you open the Changes Styles, choose tab Colour Theming and check Enable colour theming. If I do this with a 36,000+ polygon shape file it takes about 24(!) seconds before I can go on. (AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6) I profiled it a bit and found out that almost the whole time is spend with constructing simple BasicStyle [1] objects. In this concrete case the problem can be solved if you reuse already created BasicStyle objects. After this fix the 24 secs go down to 0.001 secs!!! I can send a patch which does this. The main problem is the expensive construction of the BasicStyle objects. When they are created a WKTFillPattern is created too. Always! Even if it is not used! The construction of such a fill pattern involves a lot of string parsing with a WKTReader, math, etc. A little bit heavy weighted in my opinion. Jon has a comment in BasicStyle that says it is done to make the GUI happy. This has to be done better! Because BasicStyle objects are constructed very often in *JUMP I cannot estimate the overall performance lost coming with this issue. Comments? - Sascha [1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle - 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] Streamlining Java2DConverter decimation
Have you also tried the Direct3D path (-Dsun.java2d.d3d=true)?
I think the results depend on the graphics hardware and driver quality.
Sascha
Larry Becker schrieb:
I did try the -Dsun.java2d.opengl=true on Windows XP and it rendered
just a little slower than the default method.
Larry
On 6/5/07, Larry Becker [EMAIL PROTECTED] wrote:
Hi Sascha,
I've done experiments with doing inline transformations (no
AffineTransform), and found that it was no faster either. One theory
to explain this is that the bottleneck is in the graphics system
itself. However, that is contradicted by other experiments that I
have done which show that if you have all of the shape objects
already, the time to plot them is not significant on modern
accelerated graphics cards (less than a second). It might be
different on X11 under Linux though.
What we need is a better understanding of where the time is being
spent, but this is difficult to achieve. So far I have not been
successful at getting the profile information needed.
I do know that the redraw process is responsible for most of the
cyclic (new generation) memory consumption in JUMP. This doesn't seem
to slow down the program much until the percent of free memory drops
to below 5 %.
regards,
Larry
On 6/5/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hi!
It's only that temp array, there are actually two. In case
of decimation the first allocated is copied over to a second
to archive tight fitting.
Not to forget the Coordinate-Point2D-Coordinate
transformations with the PointConverter, which also
introduces a lot of temporal object allocation. The
new created GeneralPaths stores another internal copy
of the data too if the moveTo()/lineTo() calls are done
to fill it.
I experimented with caching the result of the
on-the-fly DirectPolygon in case of filled polygons
where the geometry is rendered twice (border + fill).
In this case the inline decimation is run twice per
polygon. You can log the transformation result from
the first rendering and associate it with last transform.
If the second path iterator call is coming you can
compare the last transform and new one and in case
of equality you can run a simple and fast replay PathIterator
for the last result. But this does _not_ lead to
speed improvements. The extra book keeping seems to be more
expensive than the simply run the decimation twice.
I've code for this, but I think we do better without this.
The streamlining is a good idea! I will do the same
optimization to LineStrings too, if you approve.
BTW: If I turn on the OpenGL backend (-Dsun.java2d.opengl=true)
the burlulc layer renders a second faster when compared to
the plain X11 backend. As soon as I've access to a 3D accelerated
MS Windows I will have a look if this holds for Direct3D too.
regards, Sascha
Larry Becker schrieb:
I don't have time to look at it closely right now, but it sounds like
a logical simplification. I hate that temp array too.
regards,
Larry
On 6/4/07, Michaël Michaud [EMAIL PROTECTED] wrote:
Hi Sascha;
Sounds interesting.
Please, let me some more time to have a closer look and see how your
code compare to the one in CVS.
Note : I made a recent change in CVS to have the resolution as a
property and modify it as needed (default=1/2 pixel) for special
renderers.
Michael
Sascha L. Teichmann a écrit :
Hi Larry, hi Michaël,
I had a look at the decimation code in Java2DConverter.
This is awesome! Congratulations! :-)
But way not go step further and streamline the model to view
coordination transform. Why to create all this temporary
Coordinate[] stuff? In the end all what matters is a PathIterator
that can handle an AffineTransform coming from Java2D.
Instead of transform the data to a temporary Coordinate array
and used this to construct GeneralPaths we can write a PathIterator
that transforms and decimates the data on-the-fly.
All we have to do is to concatenate the model to view transform to the
incoming matrix.
To archive this we must add a
AffineTransform getModelToViewTransform();
method to the Java2DConverter.PointConverter interface. This
does not hurt because Viewport already implements it.
To see what I mean, look at the DirectPolygonShape that I've
attached. It handles the Polygon case of Java2DConverter.
Add this class to the sources and change the toShape(Polygon)
method to look as follow:
private Shape toShape(Polygon polygon) throws
NoninvertibleTransformException
{
return new DirectPolygonShape(
polygon,
pointConverter.getModelToViewTransform(),
1d / (2d*pointConverter.getScale()));
}
Speaking of performance. On my computer
(very old 1.2 GHz AMD/Athlon-T-Bird running GNU/Linux, Java 6)
the burluc layer is rendered in full extend without the streamling
in about 9.x seconds, with the streamling in about 8.x secs, with
x varying a bit. It's just a second, but it's a second
Re: [JPP-Devel] Expensive construction of BasicStyle objects.
So, that should fix it Added an 'if (fillPattern == null)' to the GUI and removed the ultra expensive pattern creation from BasicStyle. The construction of 100,000 BasicStyle objects now take 0.267 secs. before it took 27.357 seconds. Find attached patches against BasicStyle and BasicStylePanel. If you like them I would commit them to the core. regards, Sascha Sascha L. Teichmann schrieb: I'll try to remove the GUI dependencies for a preset fill pattern, but I also want to make BasicStyle more light weighted. I'll have a look at it later. - Sascha Larry Becker schrieb: Hi Sascha, Great work! You have found the cause of another annoying slowdown. I first noticed this doing the burlulc benchark with Colour Theming. It really needs to be fixed. I noticed that it is fixed in Kosmo already, however their model is probably different. Fixing BasicStyle to use a more lightweight fill pattern construction method would be a good idea. I'm not sure why we can't just have every new instance point to the same default copy stashed somewhere. regards, Larry On 6/5/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote: Hi together! I was wondering why it takes so long to enable Colour Theming when working with layers with a higher number of features. If you open the Changes Styles, choose tab Colour Theming and check Enable colour theming. If I do this with a 36,000+ polygon shape file it takes about 24(!) seconds before I can go on. (AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6) I profiled it a bit and found out that almost the whole time is spend with constructing simple BasicStyle [1] objects. In this concrete case the problem can be solved if you reuse already created BasicStyle objects. After this fix the 24 secs go down to 0.001 secs!!! I can send a patch which does this. The main problem is the expensive construction of the BasicStyle objects. When they are created a WKTFillPattern is created too. Always! Even if it is not used! The construction of such a fill pattern involves a lot of string parsing with a WKTReader, math, etc. A little bit heavy weighted in my opinion. Jon has a comment in BasicStyle that says it is done to make the GUI happy. This has to be done better! Because BasicStyle objects are constructed very often in *JUMP I cannot estimate the overall performance lost coming with this issue. Comments? - Sascha [1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Index: src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java === RCS file: /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java,v retrieving revision 1.1 diff -u -r1.1 BasicStyle.java --- src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java 16 Jun 2005 22:53:48 - 1.1 +++ src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java 5 Jun 2007 16:27:42 - @@ -56,18 +56,23 @@ private boolean renderingLinePattern = false; private boolean renderingFillPattern = false; + public static final Color DEFAULT_FILL_COLOR = new Color(0, 0, 0, 255); + public static final Color DEFAULT_LINE_COLOR = DEFAULT_FILL_COLOR; + public static final BasicStroke DEFAULT_FILL_STROKE = new BasicStroke(1); + //The important thing here is the initial alpha. [Jon Aquino] -private Color fillColor = new Color(0, 0, 0, 255); -private Color lineColor = new Color(0, 0, 0, 255); +private Color fillColor = DEFAULT_FILL_COLOR; +private Color lineColor = DEFAULT_LINE_COLOR; + private BasicStroke lineStroke; -private Stroke fillStroke = new BasicStroke(1); +private Stroke fillStroke = DEFAULT_FILL_STROKE; private boolean enabled = true; private String linePattern = 3; //Set fill pattern to something, so that the BasicStylePanel combobox won't //start
Re: [JPP-Devel] Expensive construction of BasicStyle objects.
The NPE comes from BasicStylePanel#findEquivalentItem()
Therefore it would vote for make this one more bullet proof.
See my new patch. I would leave BasicStyle#getFillPattern()
untouched.
Larry Becker schrieb:
It seem to work when I modify getFillPattern in BasicStyle to include
the check for null and then initialize the fillPattern as before.
public Paint getFillPattern() {
if (fillPattern == null) {
fillPattern = WKTFillPattern.createDiagonalStripePattern(4,
2, false, true);
}
return fillPattern;
}
The only side effect is that initially in the Change Styles Rendering
Tab, the Fill pattern is 0 grey. However when you check the Fill
pattern check box, it turns solid black and works correctly so I don't
see this as an issue.
regards,
Larry
On 6/5/07, Larry Becker [EMAIL PROTECTED] wrote:
Sascha,
I implemented your changes in SkyJUMP to BasicStyle and
BasicStylePanel. It worked when I opened a task with colour theming
already set up, but when I tried to add a new layer and chose Change
Styles, I got:
java.lang.NullPointerException
at
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
at
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
at
com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.init(RenderingStylePanel.java:189)
at
com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
regards,
Larry
On 6/5/07, Paul Austin [EMAIL PROTECTED] wrote:
Sascha,
In your comments you said you added an if statement but used the ?:
operator, I think in this case a proper if {} else {} statement would be
much more readable. I think that the ?: operator should be used
minimally, for example if you were generating HTML and wanted to
optionally include an attribute on a tag.
+fill = fill == null
+? fillPatternComboBox.getItemAt(0)
+: findEquivalentItem(fill, fillPatternComboBox);
BTW does this improvement only improve speed if you have a themed layer
or will it speed up all layers?
Paul
-
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/
Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
retrieving revision 1.4
diff -u -r1.4 BasicStylePanel.java
--- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 May
2007 13:24:55 - 1.4
+++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 Jun
2007 17:57:16 -
@@ -457,8 +457,12 @@
//Because fillPatternComboBox is not editable, we must use
findEquivalentItem,
//otherwise the combobox gets confused and a stack overflow occurs
//if the two items are equal but not == . [Jon Aquino]
-fillPatternComboBox.setSelectedItem(findEquivalentItem(
-basicStyle.getFillPattern(), fillPatternComboBox));
+
+ Object fill =
findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
+
+ if (fill != null)
+
fillPatternComboBox.setSelectedItem(fill);
+
updateControls();
}
@@ -477,6 +481,16 @@
}
private Object findEquivalentItem(Object item, JComboBox comboBox) {
+
+ if (comboBox == null)
+ return null;
+
+ if (item == null) {
+ return comboBox.getItemCount() 0
+ ? comboBox.getItemAt(0)
+ : null;
+ }
+
for (int i = 0; i comboBox.getItemCount(); i++) {
if (item.equals(comboBox.getItemAt(i))) {
return comboBox.getItemAt(i);
-
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.
Re: [JPP-Devel] new files changelog, changes and todo on CVS
P.S - Stefan: What is the difference between the Changes file and the ChangeLog files? Even if I'm not Stefan: Changes.txt is summary of ChangeLog. Very useful for releases and show the progress to the users. They are not interested in the technical details. Look at [1] and [2] to see what I mean. - Sascha [1] http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/Changes.txt [2] http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/Changes.txt?revision=1.4 - 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] Expensive construction of BasicStyle objects.
Okay,
I 'grep'ed the sources carefully and could not find any other
place were it may come to problems. I've tested the styling stuff
quiet intensively now and I feel pretty sure about this patches.
If no one disapproves I will commit them tomorrow.
- Sascha
Larry Becker schrieb:
Works great and has no side effects that I have found.
Larry
On 6/5/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
The NPE comes from BasicStylePanel#findEquivalentItem()
Therefore it would vote for make this one more bullet proof.
See my new patch. I would leave BasicStyle#getFillPattern()
untouched.
Larry Becker schrieb:
It seem to work when I modify getFillPattern in BasicStyle to include
the check for null and then initialize the fillPattern as before.
public Paint getFillPattern() {
if (fillPattern == null) {
fillPattern = WKTFillPattern.createDiagonalStripePattern(4,
2, false, true);
}
return fillPattern;
}
The only side effect is that initially in the Change Styles Rendering
Tab, the Fill pattern is 0 grey. However when you check the Fill
pattern check box, it turns solid black and works correctly so I don't
see this as an issue.
regards,
Larry
On 6/5/07, Larry Becker [EMAIL PROTECTED] wrote:
Sascha,
I implemented your changes in SkyJUMP to BasicStyle and
BasicStylePanel. It worked when I opened a task with colour theming
already set up, but when I tried to add a new layer and chose Change
Styles, I got:
java.lang.NullPointerException
at
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
at
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
at
com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.init(RenderingStylePanel.java:189)
at
com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
regards,
Larry
On 6/5/07, Paul Austin [EMAIL PROTECTED] wrote:
Sascha,
In your comments you said you added an if statement but used the ?:
operator, I think in this case a proper if {} else {} statement would be
much more readable. I think that the ?: operator should be used
minimally, for example if you were generating HTML and wanted to
optionally include an attribute on a tag.
+fill = fill == null
+? fillPatternComboBox.getItemAt(0)
+: findEquivalentItem(fill, fillPatternComboBox);
BTW does this improvement only improve speed if you have a themed layer
or will it speed up all layers?
Paul
-
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/
Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
retrieving revision 1.4
diff -u -r1.4 BasicStylePanel.java
--- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13
May 2007 13:24:55 - 1.4
+++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5
Jun 2007 17:57:16 -
@@ -457,8 +457,12 @@
//Because fillPatternComboBox is not editable, we must use
findEquivalentItem,
//otherwise the combobox gets confused and a stack overflow occurs
//if the two items are equal but not == . [Jon Aquino]
-fillPatternComboBox.setSelectedItem(findEquivalentItem(
-basicStyle.getFillPattern(), fillPatternComboBox));
+
+ Object fill =
findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
+
+ if (fill != null)
+
fillPatternComboBox.setSelectedItem(fill);
+
updateControls();
}
@@ -477,6 +481,16 @@
}
private Object findEquivalentItem(Object item, JComboBox comboBox) {
+
+ if (comboBox == null)
+ return null;
+
+ if (item == null) {
+ return comboBox.getItemCount() 0
+ ? comboBox.getItemAt(0)
+ : null;
+ }
+
for (int i = 0; i
Re: [JPP-Devel] new files changelog, changes and todo on CVS
Hi, Michaël Michaud schrieb: Hi, Thanks Stefan, Is there a way to use sourceforge cvs log to help completing the changelog file you just added ? There are several tools for this out there. cvs2cl.pl [1] e.g is working fine. But ones again: Writing a ChangeLog this way is only for the lazy. ChangeLog changes should be checked in each time you do a check in. About the todo list, we may have to choose a central place. There are some todo lists on the wiki, there is the sourceforge feature request, the sourceforge bug report and now here... What others think ? Central one in the source. Wikis are not reliable in the long term. It's not working off-line, depends on a internal data base structure not accessible to to user (migration issues). - Sascha [1] http://www.red-bean.com/cvs2cl/ - 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] Unstable branch of the OpenJUMP CVS...
I would prefer the following: 1 monthn-month (n+1)-month --\ devel-\...---\--\-\-- \ \ \ \ \ release 1.2 ---\ \ \ \ \ \ release 1.3 Have one current stable and one devel branch. No support for older versions. You can do this if you have enough man power. Which we don't have at the moment. I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 - 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 - 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features. But the development/release model should not be set in stone. It depends on the man power (which hopefully will increase). All it have to be is that has to be transparent to the users. - Sascha Michaël Michaud schrieb: Hi, I can see several ways to manage stable/development versions (mainly depending on how much effort we can put in maintaining all the stuff - not much until now). Hope my ascii art will be readable 1 - The most simple (CVS must be always clean and releases are done after a period where every developper concentrate on tests and bug fixes) --- Development version (CVS) \ \ release 1.2 release 1.3 2 - Stable versions are derived from development CVS as needed (bugs fixes are done on both branches during some weeeks, but the development branche is ging on without threatening the stable one) --- Development version (CVS) \ \ ---1.2 1.3 Bug fixing 3 - Two branches (needs to take new developments of the development branch, to backport them and to test them in the stable branch) --- Development version \ \ \ \ \ \ Syncronization work --- Stable branch It seems to me that we have not enough development resource to do more than [2], but I'm not a professional developper, and I may ignore how we can organize ourself to have a stable branch and a development branch without loosing too much energy. My two cents Michaël Stefan Steiniger a écrit : Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Hi Stefan, Sorry, I've a lot do this weekend (non IT stuff). Therefore I cannot offer concrete help before Monday. The best way of understanding CVS branching and merging is in my opinion the 5th chapter of the CVS book. [1] So long, Sascha [1] http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC54 Stefan Steiniger schrieb: hei guys, while reading the eclipse doc i am not figuring out if we can use branching or if we need to setup a new module (that would contain only the src folder)? if we setup a new module... how would be the easiest way to transfer the changes to stable version does anybody have experiences with branches or something like that? stefan Stefan Steiniger schrieb: Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SVG support for WMS layers
Hi together, To give a little status report about my recent improvements of the WMS layer stuff: - Introduction of a factory model that handles different formats (mime-types) more clearly and abstract. This helps to handle the result streams coming from the HTTP responses. e.g images/svg+xml needs some XML parsing, images/png can be processed by javax.imageio.ImageIO - Usage of javax.imageio.ImageIO in case of bitmap images. If things like JAI ImageIO is installed a wider range of bitmap types are supported. - Usage of the Apache Common's HttpClient [1]. This enables better HTTP handling: persistent connections, queueing, limiting number of connections to servers, performing better with multiple Threads (pooling) and so on. It also enables us to use authentication, SSL, proxies. This may be of interest when connecting to protected servers. I will suspend my further development on this stuff till the unstable/development branch comes into existence. I don't want to commit it to the stable branch, because there are questions to talk about, improving the GUI e.g. If several mime-types are available I don't think that it is a bright idea to select it by internal 'magic'. Please let me, how and when I should proceed. I do this WMS stuff in my free time, so I have no time to waste it for things that went to the nirvana of cool but unpublished software. I've done to much of this in the past. Kind regards, Sascha [1] http://jakarta.apache.org/commons/httpclient/ Sunburned Surveyor schrieb: Sascha, I agree with your comments. Let me talk to Stefan about this. I think creating a development branch of the CVS shouldn't be too much of a problem. I don't know a lot about CVS, but as long as it was fairly simple to move things from the unstable branch to the stable branch I think this would be a great idea. The Sunburned Surveyor On 5/29/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote: SS, Sunburned Surveyor schrieb: [...] I think we would definitely be interested in having the ability to render WMS layers as from SVG instead of as an image in OpenJUMP. However, I think we might benefit from the creation of an unstable or development branch in the OpenJUMP CVS were we can commit these rather rapid changes. Stefan and I discussed this a little bit before, but never moved on it. I _really_ would appreciate such a branch. Look at the concrete WMS/SVG case. I've done it now. Where should I put it? To the one and only stable branch? This not a good idea. Not because it does not work, but it surely needs a final touch and some discussions. At the moment there is no way in the WMS GUI panel to choose the preferred MIME type of the WMS response. There is some internal guessing about going on which in my eyes needs more user interaction. But we can't discuss this detail before we all aren't able to see the concrete problem in form of a running program. On the other hand I can work on a solution all by myself and send a big patch after a while. This is not the community way of doing software development... - Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SVG support for WMS layers
SS, this is okay to me. I strongly vote for an development branch _inside_ the OpenJUMP CVS. From the technical side this makes merging easier. Strategically one of *JUMP weaknesses is the existence of so many forks. For volunteers as well as for the commercial and the scientific guys a common basis is needed. Till now most of the real development has been done in the forks/flavors and ported back to OpenJUMP. I don't know if this is the right way to go in the long term. You will attract more people if OJ will get a dynamic of its own. I see potential here ... My 2 cents, Sascha Sunburned Surveyor schrieb: Sascha, Please see my comments below. Sascha wrote: I will suspend my further development on this stuff till the unstable/development branch comes into existence. I don't want to commit it to the stable branch, because there are questions to talk about, improving the GUI e.g. If several mime-types are available I don't think that it is a bright idea to select it by internal 'magic'. I e-mailed Stefan about the best place for an unstable branch of OpenJUMP's code base. When we have talked about it and made a decision I will report back to the list. If we don't create an unstable branch in the OpenJUMP CVS at the JPP SourceForge site then we will create one in the SVN repository at the SurveyOS SourceForge site. As soon as the decision has been made I will make the necessary changes and/or additions to the selected repository and will post the access information to this mailing list. You wrote: Please let me, how and when I should proceed. I do this WMS stuff in my free time, so I have no time to waste it for things that went to the nirvana of cool but unpublished software. I've done to much of this in the past. I repsect this decision. Please give me a few days to get this taken care of, and then your work on WMS can proceed. We really appreciate any volunteer effort that is put in by the members of our community and I think you are already proving to be a valuable member of that community. (Anyone that can hold his own during a discussion of JUMP source code with Larry Becker has my vote.) :] The Sunburned Surveyor On 6/1/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote: Hi together, To give a little status report about my recent improvements of the WMS layer stuff: - Introduction of a factory model that handles different formats (mime-types) more clearly and abstract. This helps to handle the result streams coming from the HTTP responses. e.g images/svg+xml needs some XML parsing, images/png can be processed by javax.imageio.ImageIO - Usage of javax.imageio.ImageIO in case of bitmap images. If things like JAI ImageIO is installed a wider range of bitmap types are supported. - Usage of the Apache Common's HttpClient [1]. This enables better HTTP handling: persistent connections, queueing, limiting number of connections to servers, performing better with multiple Threads (pooling) and so on. It also enables us to use authentication, SSL, proxies. This may be of interest when connecting to protected servers. I will suspend my further development on this stuff till the unstable/development branch comes into existence. I don't want to commit it to the stable branch, because there are questions to talk about, improving the GUI e.g. If several mime-types are available I don't think that it is a bright idea to select it by internal 'magic'. Please let me, how and when I should proceed. I do this WMS stuff in my free time, so I have no time to waste it for things that went to the nirvana of cool but unpublished software. I've done to much of this in the past. Kind regards, Sascha [1] http://jakarta.apache.org/commons/httpclient/ Sunburned Surveyor schrieb: Sascha, I agree with your comments. Let me talk to Stefan about this. I think creating a development branch of the CVS shouldn't be too much of a problem. I don't know a lot about CVS, but as long as it was fairly simple to move things from the unstable branch to the stable branch I think this would be a great idea. The Sunburned Surveyor On 5/29/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote: SS, Sunburned Surveyor schrieb: [...] I think we would definitely be interested in having the ability to render WMS layers as from SVG instead of as an image in OpenJUMP. However, I think we might benefit from the creation of an unstable or development branch in the OpenJUMP CVS were we can commit these rather rapid changes. Stefan and I discussed this a little bit before, but never moved on it. I _really_ would appreciate such a branch. Look at the concrete WMS/SVG case. I've done it now. Where should I put it? To the one and only stable branch? This not a good idea. Not because it does not work, but it surely needs a final touch and some discussions. At the moment there is no way in the WMS GUI panel to choose the preferred MIME type
Re: [JPP-Devel] A new ThreadQueue ...
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. When is empty, there are no
more render jobs to process.
This is wrong. Say you have enqueued three jobs.
The defaultRendering ThreadQueue is limited to one Thread running
so all threads are working one after each other. After the first
job has endend, the one and only Thread brings the counter to zero
because this if the only thread working on the jobs. But there are
two more in the queue. It is not important if the GUI thread is
blocked. There are two jobs more to do. And more problems arrive
if you have jobs that are _not_ in the default rendering ThreadQueue
like WMS. They are rendered in truly parallel way with a second
thread. Your 'while (default queue has running threads) sleep(time)'
loop don't test this second queue.
BTW: Didn't you mention that you place a
try { ... } catch (ArrayIndexOutOfBoundsException ex) { ...}
workaround in your SkyJUMP code? Have you ever thought about
the reasons? Looking at the code of OJ I didn't find this
'improvement' ...
This has been an interesting discussion, but we could go back and
forth like this forever. I admit that you know Threads very well, and
that your design appears to be better. I'm simply saying that JUMP
ThreadQueue is not as bad as you are making it out to be, and that it
has been working perfectly fine for years now. Could it be improved?
Of course, Jon's comments show he was constantly seeking improvements
to it. I am just cautious about replacing a critical section of code
without adequate testing. Give me a well tested bad design over an
untested good design any day.
I totally agree with you. Never touch a running system. But the system
is not running very well here. Nobody wrote code in the past that needs
precise reliability in this thread issues. This has changed.
And as you say: It's a critical portion of the code. For this kinds
of code I demand 'nearly' (*) mathematical correctness. And talking
about business: I have a customer here how stumbled into this concrete
thread trap. Now I can show him my analysis and my enhancements and how
the issue is able to be fixed. I can send him a patch set against OJ to
make his private copy work. But I prefer to fix the problem at the root
and discuss it with the OJ team.
Don't get me wrong, I do appreciate your hard work and contribution.
I just need a little more time to test.
This why are talking about and I'm willing to give you this time. :-)
regards,
Larry
(*) Having in mind Knuth's famous quotation about correctness proves and
tests.
Regards,
Sascha
On 5/30/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hi Larry,
the magic word here is 'critical region'
Have a look a the finally block.
Assume the setRunningThreads(getRunningThreads() - 1) call
was executed and the counter went to zero. This is done in Thread A.
And now directly comes a context switch to your code
in Thread B. Your if statement thinks that there are no
jobs any more - Your loop ends. Context switch back to Thread A.
Now the processQueue() call is executed and potentially a
new thread is started because the queue is not empty.
Counter is zero but queue not empty.
Thread programming is delicate, isn't it?
- Sascha
Larry Becker schrieb:
Hi Sascha,
I do not see the difference. It seems to me that when a task is
finished, the runningThreads count is decremented as in:
try {
runnable.run();
} finally {
setRunningThreads(getRunningThreads() - 1);
processQueue();
}
So it would seem to me that when the count reaches zero that there are
no more jobs.
regards,
Larry
On 5/30/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hi Larry,
The method is named runningThreads(). This was my
mistake. I will add add get getRunningThreads() to
reestablish compatibility. Thanks for this hint.
BTW: You're code:
while (threadQueue.getRunningThreads() 0) Thread.sleep(200);
tests if there are running _threads_ left. This do not tell
you if there are _jobs_ to to! What you really want to know
is when the last job is done. See the difference?
The new RenderingManager will have a new method to archive
this. It will switch the thread queue to single threaded mode
and enqueues a special Runnable at the end. Then the calling
thread is lock with a monitor. If the special Runnable is
executed the monitor is unlocked and the calling thread continues.
This is what you want.
Switching to single thread mode has the advantage to keep
the correct z order of the layers. This is essential for
printing because you don't want to have any internal repaint()
operations
Re: [JPP-Devel] WMS Problems
Hello Nacho, you are right. These strange characters prevents OJ from working with this server. I patched my local source copy of OJ com.vividsolutions.wms.WMService#initialize() to resolve the problem: ... PushbackInputStream fake = new PushbackInputStream(inp); int x; while ((x = fake.read()) != -1 x != ''); if (x == -1) throw new IOException(EOF); fake.unread(x); Parser p = new Parser(); cap = p.parseCapabilities(this, fake); ... This makes the server usable. But this is a bit of a workaround. I think it would be better to contact the server's owner to remove the characters in front of the XML document. Any other comments? BTW: A nice server to test my new SVG support for WMS. Thanks! :-) Kind regards, Sascha Nacho Uve schrieb: Hello, WMS Service doesnt work in OpenJUMP: http://ideg.xunta.es/wms/request.aspx This is a service of the Regional Governement Of Galicia (Spain) and I would like use. The problem could be the answer to the GetCapabilities: (http://ideg.xunta.es/wms/request.aspx?VERSION=1.1.1REQUEST=GetCapabilitiesSERVICE=WMS; http://ideg.xunta.es/wms/request.aspx?VERSION=1.1.1REQUEST=GetCapabilitiesSERVICE=WMS;) **?xml version=1.0 encoding=UTF-8? !DOCTYPE WMT_MS_Capabilities SYSTEM http://ideg.xunta.es/WMS/schemas/capabilities_1_1_1.dtd;[ !ELEMENT VendorSpecificCapabilities EMPTY] WMT_MS_Capabilities updateSequence=5 version=1.1.1 . . I suppous that strange characters in the head are the problem... Can we solve the problem ignoring these characters? Thank you... Regards, Nacho - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] ChartPlugIn by Geoffrey Roy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, it wasn't my intention to break out of the thread. I made a little cp mistake .. - - Sascha Roman Isitua schrieb: Hello Guys, My questions is to Geoffrey Roy and all users of his chart plugin. 1. Can stand alone charts be created for a layers attributes using this plugin ? i.e. charts that are not drawn on features. 2. If not are they plans to implement this functionality ? 3. Are they other chart plugins available for openjump? Thanks for the Good work Roman Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ - 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXJEHsrvOlFf8EzcRAr7SAKDo64BfCRhSmI9NjJN62tLZ6dxWpgCgjPbK e+PY9YdpBB4sOVFqvgfNm/w= =++ja -END PGP SIGNATURE- - 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 ...
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 'log' file. I agree, and I use small text files to store a change log for each Java class in my own programming work. Perhaps I similar system would meet your needs. If you have any ideas for a change log that we can use in the OpenJUMP CVS throw it out and we can consider it. As long as the format of the change log was simple and consistent I would have no problem with this. Tell us what you had in mind for a change log and we will see what Stefan and the others think. The format of a ChangeLog file is pretty simple and pretty standard. To see what I mean look a the ChangeLog of the Print/Layout[1] or WFS[2] plug-ins. Most of entries are pretty trivial, short and technical. A second level ChangeLog called Changes.txt summarizes the changes for the end users. It also helps the release managers to keep track of what is done. A TODO.txt file is also very helpful. A lot of open source projects are using this scheme (with variations). - Sascha [1] http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/ChangeLog?revision=1.186 [2] http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/ChangeLog?revision=1.47 - 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] SVG support for WMS layers
SS, Sunburned Surveyor schrieb: [...] I think we would definitely be interested in having the ability to render WMS layers as from SVG instead of as an image in OpenJUMP. However, I think we might benefit from the creation of an unstable or development branch in the OpenJUMP CVS were we can commit these rather rapid changes. Stefan and I discussed this a little bit before, but never moved on it. I _really_ would appreciate such a branch. Look at the concrete WMS/SVG case. I've done it now. Where should I put it? To the one and only stable branch? This not a good idea. Not because it does not work, but it surely needs a final touch and some discussions. At the moment there is no way in the WMS GUI panel to choose the preferred MIME type of the WMS response. There is some internal guessing about going on which in my eyes needs more user interaction. But we can't discuss this detail before we all aren't able to see the concrete problem in form of a running program. On the other hand I can work on a solution all by myself and send a big patch after a while. This is not the community way of doing software development... - Sascha - 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] 'import' statements in OJ
I would suggest to remove the duplicates and the needless ones. The unfolding of the star imports can be done later. I'm willing to do this. If you do the next JUMP/OJ merge rerun the script to find out which new defects are introduced. - Sascha Stefan Steiniger schrieb: i have no concern. But I have to add, that I left the imports as they have been in the Jump cvs, to avoid to much confusion when i do updates/sync with the original Jump by Vividsolutions (using the eclipse diff tool). But as they don't develop further since 5 months.. stefan Sascha L. Teichmann schrieb: Hi together, I run a little script [1] against the source of OpenJUMP to find out the improper use of 'import' statements. Here's the result: '*' import(s): 507 Star imports are name space polluters and should be better written as a list of explicit imports. Star imports are often used for convenience only. needless import(s): 286 Importing things that are not really needed introduce extra source level dependencies. If you import e.g. 'com.vividsolutions.jump.workbench.plugin.ThreadedBasePlugIn' and don't use it in the rest of the source file it can be avoided. duplicated import(s): 4 simply redundant imports. e.g. importing 'com.vividsolutions.jump.feature.Feature' twice is not necessary. For details see the attached file 'import-flaws.txt' You may call this only a 'cosmetical' weakness but I see it a context of cleaner source code. Nevertheless I would like to correct it. Anyone against it? There are other weaknesses as well: - Wrong JavaDoc syntax. contently wrong JavaDoc, missing JavaDoc. - source code encoding flaws. Some of the french and german sources are not stored in UTF-8 e.g. These issues need a more detailed analysis. Kind regards, Sascha [1] intevation.de/~teichmann/stuff/check-imports.py src/com/vividsolutions/jump/algorithm/EuclideanDistanceToPoint.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/algorithm/LengthSubstring.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/algorithm/LengthToPoint.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/algorithm/LocatePoint.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/algorithm/PointPairDistance.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/algorithm/VertexHausdorffDistance.java # '*' imports(s) com.vividsolutions.jts.geom.* # needless import(s): com.vividsolutions.jump.geom.LineSegmentUtil src/com/vividsolutions/jump/coordsys/Reprojector.java # needless import(s): com.vividsolutions.jump.feature.Feature src/com/vividsolutions/jump/coordsys/impl/Albers.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/coordsys/impl/Mercator.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/coordsys/impl/MeridianArcLength.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/coordsys/impl/Polyconic.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/coordsys/impl/TransverseMercator.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/coordsys/impl/UniversalTransverseMercator.java # '*' imports(s) com.vividsolutions.jump.coordsys.* src/com/vividsolutions/jump/datastore/DataStoreDriver.java # needless import(s): com.vividsolutions.jump.workbench.datastore.ConnectionManager src/com/vividsolutions/jump/datastore/FilterQuery.java # '*' imports(s) com.vividsolutions.jts.geom.* src/com/vividsolutions/jump/datastore/jdbc/JDBCUtil.java # '*' imports(s) com.vividsolutions.jump.datastore.* java.sql.* src/com/vividsolutions/jump/datastore/jdbc/ResultSetBlock.java # '*' imports(s) java.sql.* src/com/vividsolutions/jump/datastore/jdbc/ValueConverter.java # '*' imports(s) com.vividsolutions.jump.feature.* java.sql.* src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java # '*' imports(s) com.vividsolutions.jts.geom.* com.vividsolutions.jts.io.* com.vividsolutions.jump.datastore.* com.vividsolutions.jump.feature.* java.io.* java.sql.* src/com/vividsolutions/jump/datastore/postgis/PostgisDSConnection.java # '*' imports(s) java.sql.* # needless import(s): org.postgresql.PGConnection src/com/vividsolutions/jump/datastore/postgis/PostgisDataStoreDriver.java # '*' imports(s) com.vividsolutions.jump.datastore.* java.sql.* # needless import(s): org.postgresql.PGConnection src/com
Re: [JPP-Devel] Bug+Fix: Loading a project made of WMS layers results in retrieving the layers sequentially.
Done.
I stumbled across this issue while i was reviewing and
and testing the thread stuff.
- Sascha
Stefan Steiniger schrieb:
Hei Sascha,
please commit!
and thanx for your participation (i think except larry there is no
further real programmer on the project)
greetings from zurich,
stefan
Sascha L. Teichmann schrieb:
Hi!
Not easy to find a accurate topic for this little bug.
If you store a project with an WMS layer in it and
load this project later, the WMS layer is not loaded
parallel any more.
Background: WMS layers are normally loaded in parallel
running threads to compensate there slow data arrival.
To archive that the layers blackboard contains a
special hint. This is done during layer construction.
This hint is not serialized when the project is saved.
When the project comes up again Java2XML calls a
constructor that does not install this hint again.
Therefore the WMS layer is treated like a normal
layer with sequential data retrieval. This can be
a significant slow down.
To reproduce this bug load a few layers from a
WMS server (e.g. [1]) store a new project, restart OJ
and load it. You will notice that the loading clock
is not rotating and that the layers pop up one after the other
slowly.
Find attached a patch against WMSLayer [2] that fixes this issue.
I did not find any entry in the issue tracker concerning this bug.
If you don't tell me that this not a bug I will commit the patch
to CVS.
Kind Regards,
Sascha
[1] http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilities
[2] com.vividsolutions.jump.workbench.model.WMSLayer
Index: ./com/vividsolutions/jump/workbench/model/WMSLayer.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/model/WMSLayer.java,v
retrieving revision 1.3
diff -u -r1.3 WMSLayer.java
--- ./com/vividsolutions/jump/workbench/model/WMSLayer.java 22 May 2007
18:11:40 - 1.3
+++ ./com/vividsolutions/jump/workbench/model/WMSLayer.java 25 May 2007
22:21:47 -
@@ -79,6 +79,7 @@
* Called by Java2XML
*/
public WMSLayer() {
+init();
}
public WMSLayer(LayerManager layerManager, String serverURL, String srs,
@@ -106,10 +107,14 @@
setSRS(srs);
this.layerNames = new ArrayList(layerNames);
setFormat(format);
+init();
+this.wmsVersion = version;
+}
+
+protected void init() {
getBlackboard().put(
RenderingManager.USE_MULTI_RENDERING_THREAD_QUEUE_KEY, true);
getBlackboard().put(LayerNameRenderer.USE_CLOCK_ANIMATION_KEY,
true);
-this.wmsVersion = version;
}
private void setService(WMService service) {
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Bug+Fix: Loading a project made of WMS layers results in retrieving the layers sequentially.
Hi!
Not easy to find a accurate topic for this little bug.
If you store a project with an WMS layer in it and
load this project later, the WMS layer is not loaded
parallel any more.
Background: WMS layers are normally loaded in parallel
running threads to compensate there slow data arrival.
To archive that the layers blackboard contains a
special hint. This is done during layer construction.
This hint is not serialized when the project is saved.
When the project comes up again Java2XML calls a
constructor that does not install this hint again.
Therefore the WMS layer is treated like a normal
layer with sequential data retrieval. This can be
a significant slow down.
To reproduce this bug load a few layers from a
WMS server (e.g. [1]) store a new project, restart OJ
and load it. You will notice that the loading clock
is not rotating and that the layers pop up one after the other
slowly.
Find attached a patch against WMSLayer [2] that fixes this issue.
I did not find any entry in the issue tracker concerning this bug.
If you don't tell me that this not a bug I will commit the patch
to CVS.
Kind Regards,
Sascha
[1] http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilities
[2] com.vividsolutions.jump.workbench.model.WMSLayer
Index: ./com/vividsolutions/jump/workbench/model/WMSLayer.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/model/WMSLayer.java,v
retrieving revision 1.3
diff -u -r1.3 WMSLayer.java
--- ./com/vividsolutions/jump/workbench/model/WMSLayer.java 22 May 2007
18:11:40 - 1.3
+++ ./com/vividsolutions/jump/workbench/model/WMSLayer.java 25 May 2007
22:21:47 -
@@ -79,6 +79,7 @@
* Called by Java2XML
*/
public WMSLayer() {
+ init();
}
public WMSLayer(LayerManager layerManager, String serverURL, String srs,
@@ -106,10 +107,14 @@
setSRS(srs);
this.layerNames = new ArrayList(layerNames);
setFormat(format);
+ init();
+ this.wmsVersion = version;
+ }
+
+ protected void init() {
getBlackboard().put(
RenderingManager.USE_MULTI_RENDERING_THREAD_QUEUE_KEY, true);
getBlackboard().put(LayerNameRenderer.USE_CLOCK_ANIMATION_KEY,
true);
- this.wmsVersion = version;
}
private void setService(WMService service) {
-
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 ...
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'. This may lead to another discussion ... hopefully in another thread. But as a professional FLOSS software engineer with customers (and J.) looking at my fingers I'll always try to be very careful with my doings. ;-) Really back to topic: Find attached a replacement for ThreadQueue [1]. To use it just overwrite the original one. This one works for the real parallel case of layer rendering too. Each time a thread finished executing its Runnable it looks into the queue if they are more jobs to do. This prevents unnecessary thread creations/shutdowns. If the queue is empty the worker thread is kept alive for 5 seconds waiting for new jobs. This results in a kind of thread pooling. @Larry: I've isolated my implementation and the OJ ThreadQueue and done a synthetic benchmark with a larger number of jobs (10,000+). My implementation works about two orders faster than the OJ one. But this is of little meaning because OJ only has to handle a number of jobs equal the number of layers. This will hardly hit 10,000+ ;-) But again: My mission is improve the structure not primarily the speed. I've tested the new ThreadQueue to some extent but I'am male(tm) after all ... potentially making mistakes. It would be very kind if someone test it too. My next step will be some clean up in the RenderingManager [2]. I'am not sure that it is really needed to have two ThreadQueues there. The effect of the single tread one can be easily simulated with a data structure like the RunnableArrayList which I've posted already. Any comments? Yours, Sascha [1] com.vividsolutions.jump.workbench.ui.renderer.ThreadQueue [2] com.vividsolutions.jump.workbench.ui.renderer.RenderingManager Sunburned Surveyor schrieb: 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
Re: [JPP-Devel] A new ThreadQueue ...
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] mailto:[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
Re: [JPP-Devel] A new ThreadQueue ...
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] mailto:[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
[JPP-Devel] A new ThreadQueue ...
; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
package com.vividsolutions.jump.workbench.ui.renderer;
import java.util.LinkedList;
/**
* This special ThreadQueue uses a single thread to do all
* the rendering instead of forking a new one for each
* incomming Runnable. If the internal queue stays empty
* for TIME_TO_WAIT milli seconds the thread shuts itself down.
*
* @author Sascha L. Teichmann ([EMAIL PROTECTED])
*/
public class SingleThreadQueue
extends ThreadQueue
{
/**
* This is the time to wait before the processing thread ends.
* (30 secs)
*/
public static final long TIME_TO_WAIT = 3L;
protected class QThread extends Thread
{
protected LinkedList queue;
public QThread() {
queue = new LinkedList();
}
public int runningThreads() {
synchronized (queue) {
return queue.size();
}
}
public void add(Runnable runnable) {
synchronized (queue) {
queue.add(runnable);
queue.notify();
}
}
public void clear() {
synchronized (queue) {
queue.clear();
}
}
public void run() {
boolean done = false;
do { // while (!done)
try {
for (;;) {
synchronized (SingleThreadQueue.this) {
if (SingleThreadQueue.this.disposed) {
done = true;
break;
}
}
Runnable runnable;
synchronized (queue) {
if (queue.isEmpty()) {
queue.wait(TIME_TO_WAIT);
if (queue.isEmpty()) {
synchronized (SingleThreadQueue.this) {
// This may look odd but it guarantees that
// no add() is done while checking for emptiness.
if (queue.isEmpty())
break;
}
}
}
runnable = (Runnable)queue.remove();
if (runnable == null)
break;
} // synchronized queue
try {
runnable.run();
}
catch (Exception e) {
e.printStackTrace();
}
} // for (;;)
}
catch (InterruptedException ie) {
done = true;
}
finally {
synchronized (queue) {
if (queue.isEmpty())
done = true;
}
synchronized (SingleThreadQueue.this) {
SingleThreadQueue.this.thread = null;
}
}
}
while (!done);
SingleThreadQueue.this.fireAllRunningThreadsFinished();
}
} // class QThread
protected boolean disposed;
protected QThread thread;
public SingleThreadQueue() {
}
public synchronized void clear() {
if (thread != null)
thread.clear();
}
public synchronized void add(Runnable runnable) {
if (disposed)
return;
if (thread == null) {
thread = new QThread();
thread.setDaemon(true);
thread.start();
}
thread.add(runnable);
}
public synchronized int runningThreads() {
return thread == null ? 0 : thread.runningThreads();
}
public synchronized void dispose() {
clear();
disposed = true;
}
}
// end of file
-
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] Caching result of WMS requests?
Hi together,
I'm currently hunting down some timing bugs in the Print/Layout plug-in.
If WMS layers are used they are not always imported correctly into
the layout sheet.
On my trip down the rendering path I found out that WMS layers
do not cache the resulting images of there requests.
I've written a patch (see attachment) against WMSLayer [1] that stores
the result of the last request using a pair of java.net.URL and
java.lang.ref.SoftReference (java.awt.Image).
If the next WMS request URL equals the last one the stored
image is used and so expensive traffic is avoid.
This does not solve my timing problem but it improves it a bit.
IMHO this little tweak improves WMS performance in general
by removing redundant HTTP traffic.
Kind regards,
Sascha
[1] com.vividsolutions.jump.workbench.model.WMSLayer
Index: src/com/vividsolutions/jump/workbench/model/WMSLayer.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/model/WMSLayer.java,v
retrieving revision 1.2
diff -u -w -r1.2 WMSLayer.java
--- src/com/vividsolutions/jump/workbench/model/WMSLayer.java 24 Jun 2005
09:01:57 - 1.2
+++ src/com/vividsolutions/jump/workbench/model/WMSLayer.java 22 May 2007
16:16:43 -
@@ -51,6 +51,11 @@
import com.vividsolutions.wms.MapRequest;
import com.vividsolutions.wms.WMService;
+import java.net.URL;
+
+import java.lang.ref.Reference;
+import java.lang.ref.SoftReference;
+
/**
* A Layerable that retrieves images from a Web Map Server.
*/
@@ -66,6 +71,10 @@
private WMService service;
private String wmsVersion = WMService.WMS_1_0_0;
+
+ protected Reference oldImage;
+ protected URL oldURL;
+
/**
* Called by Java2XML
*/
@@ -121,7 +130,20 @@
}
public Image createImage(LayerViewPanel panel) throws IOException {
- Image image = createRequest(panel).getImage();
+
+ MapRequest request = createRequest(panel);
+ URLnewURL = request.getURL();
+
+ Image image;
+
+ // look if last request equals new one.
+ // if it does take the image from the cache.
+ if (oldURL == null
+ || !newURL.equals(oldURL)
+ || oldImage == null
+ || (image = (Image)oldImage.get()) == null
+ ) {
+ image = request.getImage();
MediaTracker mt = new MediaTracker(new JButton());
mt.addImage(image, 0);
@@ -130,6 +152,9 @@
} catch (InterruptedException e) {
Assert.shouldNeverReachHere();
}
+ oldImage = new SoftReference(image);
+ oldURL = newURL;
+ }
return image;
}
-
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] Caching result of WMS requests?
done. :-)
Stefan Steiniger schrieb:
Hei Sascha,
thanx a lot.
are you going to commit it the openjump cvs repository?
would be nice :o)
stefan
Sascha L. Teichmann schrieb:
Hi together,
I'm currently hunting down some timing bugs in the Print/Layout plug-in.
If WMS layers are used they are not always imported correctly into
the layout sheet.
On my trip down the rendering path I found out that WMS layers
do not cache the resulting images of there requests.
I've written a patch (see attachment) against WMSLayer [1] that stores
the result of the last request using a pair of java.net.URL and
java.lang.ref.SoftReference (java.awt.Image).
If the next WMS request URL equals the last one the stored
image is used and so expensive traffic is avoid.
This does not solve my timing problem but it improves it a bit.
IMHO this little tweak improves WMS performance in general
by removing redundant HTTP traffic.
Kind regards,
Sascha
[1] com.vividsolutions.jump.workbench.model.WMSLayer
Index: src/com/vividsolutions/jump/workbench/model/WMSLayer.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/model/WMSLayer.java,v
retrieving revision 1.2
diff -u -w -r1.2 WMSLayer.java
--- src/com/vividsolutions/jump/workbench/model/WMSLayer.java24 Jun
2005 09:01:57 - 1.2
+++ src/com/vividsolutions/jump/workbench/model/WMSLayer.java22 May
2007 16:16:43 -
@@ -51,6 +51,11 @@
import com.vividsolutions.wms.MapRequest;
import com.vividsolutions.wms.WMService;
+import java.net.URL;
+
+import java.lang.ref.Reference;
+import java.lang.ref.SoftReference;
+
/**
* A Layerable that retrieves images from a Web Map Server.
*/
@@ -66,6 +71,10 @@
private WMService service;
private String wmsVersion = WMService.WMS_1_0_0;
+
+protected Reference oldImage;
+protected URL oldURL;
+
/**
* Called by Java2XML
*/
@@ -121,7 +130,20 @@
}
public Image createImage(LayerViewPanel panel) throws IOException {
-Image image = createRequest(panel).getImage();
+
+MapRequest request = createRequest(panel);
+URLnewURL = request.getURL();
+
+Image image;
+
+// look if last request equals new one.
+// if it does take the image from the cache.
+if (oldURL == null
+|| !newURL.equals(oldURL)
+|| oldImage == null
+|| (image = (Image)oldImage.get()) == null
+) {
+image = request.getImage();
MediaTracker mt = new MediaTracker(new JButton());
mt.addImage(image, 0);
@@ -130,6 +152,9 @@
} catch (InterruptedException e) {
Assert.shouldNeverReachHere();
}
+oldImage = new SoftReference(image);
+oldURL = newURL;
+}
return image;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] I could really use some help with this question on the RenderingManager...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SS,
Unit test is fine, but take a suggestion wrong an old coder:
println debugging has its merits and setting a break point
in your debugger to introspect some variables may save your day. ;-)
- - Sascha
Sunburned Surveyor schrieb:
Sascha,
This is how the method was coded first, and I still got the error
message. I changed it today thinking that might fix the problem.
Do you have any other ideas?
The Sunburned Surveyor
On 5/21/07, Sascha L. Teichmann [EMAIL PROTECTED] wrote:
Hi,
What about rewriting
getRenderer(contentID).equals(null)
as
getRenderer(contentID) == null
?
- Sascha
Sunburned Surveyor schrieb:
I'm about ready to give up on this pluggable rendering system for
OpenJUMP. :]
I created JUnit tests for the two main classes involved, namely
RendererFactory and RegularRendererFactoryTool. All the JUnit tests
for the public methods in both the classes pass with no problems now
that I have made some corrections to my code.
I built OpenJUMP today so that I could test the modified code.
OpenJUMP opens but gives me an error message after displaying the
layer view. The error message is again a NullPointerException but this
time it is coming from the render() method of the RenderingManager
class which seems odd.
The line that is generating the error mesage is this:
if (getRenderer(contentID).equals(null))
This really confuses me, since it seems that we are calling the
getRendererMethod which is defined in the same class,
RenderingManager, that also defines the render() method that is
throwing an exception.
How can I be generating a NullPointerException from this method? If
the NullPointerException was coming from inside the getRenderer()
method itself, wouldn't that be indicated in the stack trace of the
exception?
I should also mention that OpenJUMP correctly renders a layer when I
am adding a new layer to the project, but that any attempts to pan or
zoom the Layer View result in the same NullPointerException that is
produced when OpenJUMP first opens.
I'm really lost with this one. Any help or suggestions of where to
look for the source of this NullPointerException would be greatly
appreciated.
Thanks in advance for the help.
The Sunburned Surveyor
P.S. - I have attached the text will all of the statements of the
RenderingManager.render() method if you want to take a look.
public void render(Object contentID, boolean clearImageCache) {
if (getRenderer(contentID).equals(null))
{
/*
* Modified this method to wrap the call to
createRenderer() in a try/catch block.
* [The Sunburned Surveyor 2007-05-02]
*
*/
try
{
setRenderer(contentID,
createRenderer(contentID));
}
catch(ExcPluggableRendererNotFound thisException)
{
System.err.println(thisException.getMessage());
}
}
if (getRenderer(contentID).isRendering()) {
getRenderer(contentID).cancel();
//It might not cancel immediately, so create a new
Renderer [Jon
// Aquino]
/*
* Modified this method to wrap the call to
createRenderer() in a try/catch block.
* [The Sunburned Surveyor 2007-05-02]
*
*/
try
{
setRenderer(contentID,
createRenderer(contentID));
}
catch(ExcPluggableRendererNotFound thisException)
{
System.err.println(thisException.getMessage());
}
}
if (clearImageCache) {
getRenderer(contentID).clearImageCache();
}
Runnable runnable = getRenderer(contentID).createRunnable();
if (runnable != null) {
// Before I would create threads that did nothing.
Now I never do
// that -- I just return null. A dozen threads that
do nothing make
// the system sluggish. [Jon Aquino]
((contentID instanceof Layerable ((Layerable)
contentID)
.getBlackboard().get(USE_MULTI_RENDERING_THREAD_QUEUE_KEY,
false)) ?
multiRendererThreadQueue
:
defaultRendererThreadQueue
Re: [JPP-Devel] wiki on sourceforge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stefan Steiniger schrieb: i just have seen, that Sourceforge now also offers a wiki. It may offer the choice to move some development related pages to that wiki. for instance changes on the cvs, needed and added new functions, Wikis are fine for documentation, but as a developer i would always vote for some of these in the CVS - - ChangeLog (developer's log), - - Changes.txt (summarized dev log for users) - - TODO.txt(guess) Pro: They will be always with the source and not scattered around in 404 suffering web space. Just my 2 cents, Sascha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS1H7srvOlFf8EzcRAnSWAKCAWmwRFileqy8nGzDz2SGHV025QQCdFXXZ ofSYVVEEZ6cYdNcsnyN/4Fw= =TW8n -END PGP SIGNATURE- - 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] wiki on sourceforge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Handwritten ChangeLogs offer the opportunity to log some extra comments and backgrounds that do not make there way into the commit message. But this is of course a question of personal taste. - - Sascha Larry Becker schrieb: A changeLog would be nice. You can auto-generate one using the changelog http://sourceforge.net/projects/cvschangelog/Eclipse tool. Check the SkyJUMP release notes to see an example (scroll to the bottom). It basically concatenates all of the CVS commit notes in time order for you. Larry On 5/16/07, *Sascha L. Teichmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Stefan Steiniger schrieb: i just have seen, that Sourceforge now also offers a wiki. It may offer the choice to move some development related pages to that wiki. for instance changes on the cvs, needed and added new functions, Wikis are fine for documentation, but as a developer i would always vote for some of these in the CVS - ChangeLog (developer's log), - Changes.txt (summarized dev log for users) - TODO.txt(guess) Pro: They will be always with the source and not scattered around in 404 suffering web space. Just my 2 cents, Sascha - - 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 mailto:Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS1l5srvOlFf8EzcRAtRyAKCl8C0lKrCshp4nHlYoErI4UZkQ3gCfQ+tu +VoX+NVLeQZ1jR94m1ln9dc= =x0y9 -END PGP SIGNATURE- - 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] SVGConvertable Inteface...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi together, The Print/Layout Plug-in is based on SVG exactly for the reason of being used in a tool chain. It would be of great to have an API that eases the SVG conversion process. I've a lot of ideas how to do it right and I'm willing to assist you if you _really_ work on this topic. Don't get me wrong, but I'm under the impression that you 'spread' out your work focus to some extend. ;-) Greets, Sascha Sunburned Surveyor schrieb: Martin, Please see my comments below. Martin wrote: Yeah... this is one way to approach it. But JUMP Layers and Features contains a lot of structured data and metadata which probably isn't available to you once you've crunched everything into Inkscape (they are totally different data models, aren't they?) So that means that in order to drive your rendering from this information, you need to do it where you have access to this information - ie. inside JUMP. (For example, think about rendering based on attribute...) I understand this point. Thank you for bringing it out. Martin wrote: I can see using Inkscape to *add to* an image generated from JUMP. This is exactly what I was talking about! I imagine that a person would do 95% of their work in OpenJUMP, and when they are ready to produce a map for printing they would export their data into SVG, open it is Inkscape, and add the finishing artistic touches there. (Actually I's use Inkscape and Scribus to produce the final map.) Martin wrote: would modularize the SVG conversion (really rendering) code out into a separate class. You're going to end up doing that anyway inside your Layer class (to prevent the code from getting totally bloated). So split it out and give it a nice API, and you have much better modularity. Think separation of concerns. Are you saying I should make the SVGConverter a class and not an interface? This would work, but I would imagine each implementation of Layerable would need a SVGConverter class with custom conversion code. For example: You'd need one set of conversion logic for image layers, another for regular vector layers, and another for my label layers. I suppose we could do this by creating an abstract SVGConverter class. Is this what you had in mind? Martin wrote: Anyway, isn't there a bigger use case involving combining several layers into one SVG drawing? The usual way to do this is to simply take all the visible Layers in a Task and render them, driving the rendering off the symbology already on the Layers. If there is special rendering that can be performed (say something like your labels), this can be driven off special attributes that the renderer recognizes. Sometimes I don't do a very good job of explaining myself. This is the process I was trying to describe. I imagine things would work like this: The user would select a set of layers that they wanted to export to a single SVG file and would select the Export to SVG command. OpenJUMP would pass each of the selected layers to the SVGConverterTool object. This object would call the convertToSVG method on each of the selected layers that implemented the SVGConvertable interface. It would take the String returned by this method, which contains the SVG representation of the layer's contents and would add or append it to a text file containing all of the svg content. The end result would be a single text file with the SVG content for all of the selected layers that supported conversion to SVG. The conversion logic would be left to the developers implementing the Layerable interface. We could even use the group elements in SVG to create layers in Inkscape that corresponded to the layers in OpenJUMP. The Sunburned Surveyor On 5/15/07, Martin Davis [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: I wanted to share some quick thoughts about SVG support in OpenJUMP. I'm a big fan of Inkscape and I think it has the potential to be a great tool for cartographic map design. Why develop a lot of cartographic design or art tools for OpenJUMP when Inkscape already has a great deal of momentum? (This isn't meant to detract from the great printing plug-ins that have developed in the last few months.) Yeah... this is one way to approach it. But JUMP Layers and Features contains a lot of structured data and metadata which probably isn't available to you once you've crunched everything into Inkscape (they are totally different data models, aren't they?) So that means that in order to drive your rendering from this information, you need to do it where you have access to this information - ie. inside JUMP. (For example, think about rendering based on attribute...) I can see using Inkscape to *add to* an image generated from JUMP. I want to post about this on my blog, but haven't had time yet. At any rate I started helping with the lib2geom effort a little bit, in an effort to contribute
Re: [JPP-Devel] Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Roman, Roman Isitua schrieb: 2. The printlayout plugin is not working each time I use it. I get the following error java.lang.NoClassDefFoundError: org/apache/batik/dom/svg/SAXSVGDocumentFactory [...] The printlayout plug-in needs more recent implementations of the Batik SVG library, FOP and some XML libs [1]. Please remove all batik jars from your jump libs dir. The XML libs listed below eventually overwrite existing ones. Back them up before if you are afraid of breaking something, but this generally not necessary because they are compatible. You have to update your CLASSPATH in the start scripts as well. Remove every entry pointing to the old libs and add the paths to _all_ of the new ones. Sorry for this inconvenience. If you have other problems with the plug-in let me know. :-) Greetings, Sascha [1] You can get them from here: http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/batik-all.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/pdf-transcoder.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/xml-apis-ext.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/xml-apis.jar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBRNfsrvOlFf8EzcRAnG/AKDQhy7k1Crn7OYnwhN0nrT/h3N7XACeOmkX Qql1qJRSw4TCsasVTcIJo0w= =6Uuk -END PGP SIGNATURE- - 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.phpp=sourceforgeCID=DEVDEV ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Make Java2DConverter exchangeable in Viewport?
Hallo together,
It would be of great if the Viewport class [1] would has a
setJava2DConverter(Java2DConverter) method.
Java2DConverter [2] objects are used to convert JTS
geometries into Java2D shapes.
Why should it be possible to exchange the converter? For the
simple reason that the default one does some coordinate rounding/cutoffs
that make it hard to produce a quality output for printing, SVG export
and so on. We discussed that earlier on the list. If it would be
possible to set a custom (actually a subclass of Java2DConverter)
converter you can temporally replace the original one for a rendering
cycle to get non-truncated vertices. Even more: you can install a
converter that does some controlled simplifications to reduce the
amount of data that is send to the output devices. I've tried both
and it works very well without having a big impact onto the rendering
process as such.
I've attached a patch to add the setter to Viewport. It would be
really kind if you test it. I don't want to simply let my commit
speak. ;-)
Thanks in advance,
Sascha
[1] com.vividsolutions.jump.workbench.ui.Viewport
[2] com.vividsolutions.jump.workbench.ui.renderer.java2D.Java2DConverter
Index: src/com/vividsolutions/jump/workbench/ui/Viewport.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/Viewport.java,v
retrieving revision 1.1
diff -u -r1.1 Viewport.java
--- src/com/vividsolutions/jump/workbench/ui/Viewport.java 16 Jun 2005
22:11:47 - 1.1
+++ src/com/vividsolutions/jump/workbench/ui/Viewport.java 19 Mar 2007
10:45:39 -
@@ -97,6 +97,10 @@
return java2DConverter;
}
+public void setJava2DConverter(Java2DConverter converter) {
+java2DConverter = converter;
+}
+
public ZoomHistory getZoomHistory() {
return zoomHistory;
}
-
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.phpp=sourceforgeCID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Make Java2DConverter exchangeable in Viewport?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
... done.
A very big thank you to Larry for supporting me in this. :-)
- From the point of view of the Print/Layout plug-in this makes it
a lot easier to produce hi quality output without tampering
with the size of the LayerViewPanel or other ugly workarounds.
Of cause on the callers side you cannot assume that the
set() call is already there [1]. Even if SkyJUMP and OpenJUMP
features it we have a bunch of other derivates.
It would be very nice to have it at least in deeJUMP or PirolJUMP
as well.
Ugo, Michael (Brüning), any comments about this topic?
- - Sascha
[1] java.lang.reflect is our friend here to check if it exists
and call it if it's possible.
Stefan Steiniger schrieb:
ok.. if Larry (from my point of view the expert) agrees, then you can
commit your patch.
stefan
Sascha L. Teichmann schrieb:
Hallo together,
It would be of great if the Viewport class [1] would has a
setJava2DConverter(Java2DConverter) method.
Java2DConverter [2] objects are used to convert JTS
geometries into Java2D shapes.
Why should it be possible to exchange the converter? For the
simple reason that the default one does some coordinate rounding/cutoffs
that make it hard to produce a quality output for printing, SVG export
and so on. We discussed that earlier on the list. If it would be
possible to set a custom (actually a subclass of Java2DConverter)
converter you can temporally replace the original one for a rendering
cycle to get non-truncated vertices. Even more: you can install a
converter that does some controlled simplifications to reduce the
amount of data that is send to the output devices. I've tried both
and it works very well without having a big impact onto the rendering
process as such.
I've attached a patch to add the setter to Viewport. It would be
really kind if you test it. I don't want to simply let my commit
speak. ;-)
Thanks in advance,
Sascha
[1] com.vividsolutions.jump.workbench.ui.Viewport
[2] com.vividsolutions.jump.workbench.ui.renderer.java2D.Java2DConverter
Index: src/com/vividsolutions/jump/workbench/ui/Viewport.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/Viewport.java,v
retrieving revision 1.1
diff -u -r1.1 Viewport.java
--- src/com/vividsolutions/jump/workbench/ui/Viewport.java 16 Jun 2005
22:11:47 - 1.1
+++ src/com/vividsolutions/jump/workbench/ui/Viewport.java 19 Mar 2007
10:45:39 -
@@ -97,6 +97,10 @@
return java2DConverter;
}
+public void setJava2DConverter(Java2DConverter converter) {
+java2DConverter = converter;
+}
+
public ZoomHistory getZoomHistory() {
return zoomHistory;
}
-
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF/3APsrvOlFf8EzcRAhWTAJsEJn1WSbZhWaksv3/iTYvejmQGhgCeI2so
iF8PDtj9vJjeFzuG59PKyZA=
=lTUC
-END PGP SIGNATURE-
-
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.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] PrintLayout Plugin 0.8.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, once again. You have to add _all_ new Jars to the CLASSPATH! Did you read my reply to Maltes Mail from 30-jan-2007? I posted a openjump.bat (from plain OpenJUMP stable) with patched CLASSPATH to include all JARS. - - Did you test that? - - Did you have downloaded _all_ the extra jars and put them into the CLASSPATH? org.w3c.dom.svg.SVGDocument for instance is in the xml-apis-ext.jar. If this one would be in the CLASSPATH Java would have found it. Needed files (besides the plugin jar of cause) - - batik-all.jar - - js.jar - - pdf-transcoder.jar - - xml-apis-ext.jar - - xml-apis.jar (overwrites an existing one!) Best regards - - Sascha Jan-Oliver Wagner schrieb: Geoffrey, On Thursday 01 February 2007 00:39, Geoffrey G Roy wrote: I have tried your 0.8.2 version, but still get an error when trying to execute the extension org.w3c.dom.svg.SVGDocument (No Class Def Found) java.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocument at java.lang.ClassLoader.defineClass1(Native Method) ... de.intevation.printlayout.PrintLayoutPlugin.run(PrintLayoutPlugin.java:63) at com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:149) at java.lang.Thread.run(Unknown Source) --- Am I missing a library jar? I confess I am puzzled. We tested the whole procedure over here and it worked. There also were two other reports on this list that it worked. And we also have some reports that it does not work for them. Looking at the reports, I see that all positive reports come from people who probably use a german Windows or Linux. Is there anyone out there who managed to run the plugin on an english Windows system? I also confess I am not a Java expert. So, any help in analysing this problem is highly appreciated. (In general I feel able though to work on a problem -- if I only could reproduce it, which is not the case). Best Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwblJsrvOlFf8EzcRAqPAAJ9EfknP4aBepyzZFVt3qERXj76sRwCbBhko pZiD28wlui9e29RbYW3MiLI= =QooE -END PGP SIGNATURE- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Rendering precision of SVG export (was PrintLayout Plugin 0.8.2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi together, Larry brought up the point that the SVG export is crappy due to rounding errors. I tracked down this issue to the point where the rounding is done. Mainly two classes are responsible for this: 1) com.vividsolutions.jump.workbench.ui.renderer.java2D.PolygonShape The coordinates are converted to integers here by using a java.awt.Polygon. Bad idea. I replaced this by a java.awt.geom.GeneralPath. 2) com.vividsolutions.jump.workbench.ui.renderer.java2D.Java2DConverter Each incoming JTS point transformed to model space is rounded to the nearest integer in #toViewPoint(). Bad idea again. I removed this rounding. A comment for this method says that there is a rounding issue in Java2D. This comment dates back to 2004. I wonder if this is still relevant nowadays?! After doing this two little modification the quality improved dramatically. See the screen shots before.png [1] and after.png [2] I strongly recommend to take this mods into CVS because all rendering via a Graphics2D context is effected by this. Printing quality e.g. suffers as well from this issue. Kind regards, Sascha [1] http://intevation.de/~teichmann/before.png [2] http://intevation.de/~teichmann/after.png -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwqHisrvOlFf8EzcRArkpAKCI7hD03CZtweL6U+uy9hdzsQ/1JgCfTAmo dgre16tGnG135ZV8/WOdEVU= =YXRP -END PGP SIGNATURE- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] PrintLayout Plugin 0.8.1
Hello Malte, Malte Weller schrieb: I got the plug-in running with the Pirol Edition of OpenJump. With the last stable release of OpenJump (1.0.1) I get the same error as Geoffrey. To test it I downloaded OpenJump 1.0.1. (the plain openjump-1.0.1.zip from SF). Then I removed the lib\batik directory and placed all extra jar files - batik-all.jar - js.jar - pdf-transcoder.jar - xml-apis-ext.jar - xml-apis.jar (overwrites an existing one!) into the lib directory. After modifying the CLASSPATH bin\openjump.bat [1] to include all these jars the plugin works fine for me. (Platform WinXP Pro/SP2 JRE 1.5.0_10-b03) Back to the running plug-in under Pirol Edition. By loading the plug-in the main window still has the focus and the plug-in window disappears to the taskbar. This happens every time the cursor moves over the main OpenJump window. I can confirm this for the OpenJump 1.0.1 as well. We'll have a look at that. If I draw a rectangle over the map (as a border for the map) I'm not able to select the map anymore. So some menu items under 'Insert' (Einfügen) are disabled (Massstabsbalken hinzufügen + Massstabstext hinzufügen). This is because the rectangle is actually a box with fill none which makes it solid. We'll fix this as soon as we get the property dialog for the rectangle. - Sascha [1] I try to include openjump.bat ... if the mail filter let it through set LIB=../lib set CLASSPATH=%LIB%/bsh-2.0b4.jar;%LIB%/Buoy.jar;%LIB%/Jama-1.0.1.jar;%LIB%/jdom.jar;%LIB%/jts-1.7.jar;%LIB%/jump-workbench-1.0.1.jar;%LIB%/jump-api-1.0.1.jar;%LIB%/xercesImpl.jar;%LIB%/xml-apis.jar;%LIB%/log4j-1.2.8.jar;%LIB%/batik-all.jar;%LIB%/js.jar;%LIB%/xml-apis-ext.jar;%LIB%/pdf-transcoder.jar REM Add extension directory to path, so extensions can put DLL's there [Jon Aquino 2005-03-18] set PATH=%PATH%;%LIB%/ext start javaw -Dlog4j.configuration=file:./log4j.xml -Xms256M -Xmx256M -cp %CLASSPATH% com.vividsolutions.jump.workbench.JUMPWorkbench -properties workbench-properties.xml -plug-in-directory %LIB%/ext - 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.phpp=sourceforgeCID=DEVDEV___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
