Re: [josm-dev] How do I add a new projection, EPSG:2924?
Frederik Ramm wrote: Dirk, [...] java.lang.ClassNotFoundException: org.openstreetmap.josm.plugins.fredprojection.FredProjection at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.openstreetmap.josm.gui.preferences.ProjectionPreference.setProjection(ProjectionPreference.java:206) [...] Class.forName(name).newInstance(); for the name of my projection (which is derived from that very instance!) fails. I'm afraid that my Java skills stop there - somehow the default class loader does not know about classes added by plugins, and would need to be made aware of them. There are two approaches possible for this problem. The simpler one would be to change ProjectionPreference to not call Class.forName(), but instead getProjections(), and iterate the registered _instances_ until getClass().getName() matches. The more complex, but generally preferable (as it would solve many similar problems once for good) would be to code a delegating class loader that would try to fulfill the load request by trying each plugin's loader in sequence. This overall loader would be then set as the context class loader of every thread. Similar to http://hg.netbeans.org/main/file/tip/o.n.bootstrap/src/org/netbeans/ProxyClassLoader.java but many many revisions ago (before the packageCoverage optimization was implemented) and simplified... Regards, Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] how to load signed jars needed by my plugin?
Christoph Wagner wrote: The other problem is, that the signatures are checked while runtime. If I ignore the signatures I get this error: java.lang.SecurityException: JCE cannot authenticate the provider BC while using the bouncycastle security provider. I don't want to hack this internal. Is there no way to load the additional jars with josm? Isn't the URLClassLoader respecting Class-Path: attribute from the manifest? You should be able to keep the library in a separate jar and reference it only from your plugin's manifest... -- Nenik ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: start of gwtosm the google webtoolkit port of josm
Ævar Arnfjörð Bjarmason wrote: Isn't josm-ng dead-ish at this point? Yes, it is. I thought it was just a one-man project whose ideas are mostly in the main josm by now, maybe I'm wrong. Some of them are in, some not. Maybe more will get into josm, but I'm personally not working on porting those remaining nice ideas... -- Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Painting
Jiri Klement wrote: One of the reason why painting appears slow is the fact that it's done in EDT thread. I think there should be special thread for painting. Disagreed (with both sentences). EDT will only send request to repaint and copy offscreen buffer to screen when it's ready. Painting thread will wait for repaint requests. When request arrives it will start painting immediately. If another request arrives during painting, it will wait. If there are multiple repaint request after painting is finished, only the last one will be processed. This is exactly what RepaintManager in Java does for you. User events (mouse gestures, ...) and posted tasks are processed and the repaint requests they caused are buffered and a repaint request is posted at the end of the event queue. Once the queue drains, the repaint happens, only once. If you think of coleascing paints across more user gestures (like continuous dragging), you'll face two problems: 1) the trade-off between UI responsivity and the amount of coalesced events. Too short delay before painting and you paint on every event anyway. Too long delay and the UI will feel slow most of the time. 2) Loss of feedback in the cases where the painting already takes considerable amount of time. Separate thread won't help you neither on multicores, as you'll keep the problem serialized. Everything else but painting is fast enough, so you'll have AWT thread idle happily waiting for next event while the painting thread will fully load one core. Well, there will be the benefit of having the rest of the UI responsive, but we're not here to solve multisecond painting of zoom-to-fit of large datasets this time, are we? As for the initial comment regarding full repaint just to do rubber-band: There's no problem with full repaint as long as you do it fast enough. And this is doable. Proved. Moreover, I fear the increased code complexity necessary for partial, maybe filtered, repaints may slow down the general painting so the net result will be worse. For the record, I've tried current JOSM and must say that the rendering speed improved a lot. What might help, IMO, is to disable painting plain points over given zoom level. JOSM already paints large datasets when zoomed in and slight simplification, when zoomed out can only improve the situation. (You don't need to see individual nodes when looking at half the Germany, do you?) Regards, Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Painting
Sebastian Klein wrote: I was wondering: Is it save to paint to the Graphics of some component from a random thread at a random time? No, it is not safe, but that's not what you'd be doing. The painting will proceed into a BufferedImage, which will then be painted in the event thread using the component's Graphics. -- Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Translations don't fit screen?
Frederik Ramm napsal(a): Hi, Ævar Arnfjörð Bjarmason wrote: Your system is fine. There just simply isn't enough space to fit that string. I've had to alter numerous strings in Icelandic to less optimal translations so that they can fit into a space designed for e.g. three letter English words. But things like the button having been cut off - doesn't Java do these things right if used correctly? Yes, if used correctly. Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Selection handling
Karl Guggisberg napsal(a): Hi Dave, I saw that your patch regarding selection handling was commited: http://josm.openstreetmap.de/ticket/3676 When you introduce a new selection cache in the future, could you make sure it's *ordered*, i.e. it reflects the order in which primitives are selected (could be a list, an ordered set, instead of a plain collection)? FYI: josm-ng used LinkedHashSet for keeping (per-layer) selection and used the order just to cover the cases you mentioned. Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Selection Performance
Dave Hansen napsal(a):
On Thu, 2009-10-08 at 00:10 -0700, Dave Hansen wrote:
It takes almost a second for me to do a mouse click and have a single
object be selected. I think it's worse for large data sets, but it
seems to exist most of the time despite the size of the data set.
Personally, I think a whole second to wait for a mouse click is pretty
bad.
Most of the time appears to be spent notifying things about the
selection change. I just counted 110 of these, and we fire once for the
clearSelection() and again for the new selection. They all seem to add
up to almost a second of latency. I actually went and printed out a
bunch of timestamps to confirm this.
Any thoughts on how to make this better? I've been using my QuadBuckets
code to make the click coordinate searches faster, but I'm clueless as
to what to do with these notifiers.
Digging in a bit more... Virtually none of these actions care about the
contents of selections. The vast majority just do:
@Override
protected void updateEnabledState() {
setEnabled(getCurrentDataSet() != null !
getCurrentDataSet().getSelected().isEmpty());
}
The problem is that getSelected() iterates over the entire data set
looked for selected OsmPrimitives. We do this ~112 times for each mouse
click. That's a bit, um, suboptimal.
I tried a really quick and dirty solution which is to just keep a copy
of the selected primitives around. That makes a *huge* difference.
First and foremost, selection status is not a property of the data.
Changing the data set just because the user have selected something is
plain wrong. Having a per-dataset selection is quite disturbing too -
there should be only one, system-wide.
Regards,
Nenik.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Selection Performance
Dave Hansen napsal(a): On Thu, 2009-10-08 at 10:18 +0200, Petr Nejedlý wrote: First and foremost, selection status is not a property of the data. Changing the data set just because the user have selected something is plain wrong. Having a per-dataset selection is quite disturbing too - there should be only one, system-wide. OK, so you're saying that because selecting things is not a property of the data that it shouldn't be a part of the data set? Uh, ok. Aren't ways and nodes part of the data set? Check out OsmPrimitive.setSelected(). Sure seems to *ME* like selections are part of the data set. Selections are currently part of the OSMPrimitive API, sure. What I'm saying is that it doesn't belong there. In the worst case, it may be the property of the DataSet, but... Karl Guggisberg napsal(a): Do you have a better suggestion on where to stick the selection cache or whatever we want to call it than in the DataSet? I think the selection cache (a collection of the currently selected primitives) should be maintained for each data layer (either by the layer or by some global selection cache which keeps a selection state per layer). If the dataset wasn't attached to a data layer why would you want to select/unselect objects? What I never liked is that there is a boolean field 'selected' on OsmPrimitive - this looks weired. ... exactly! Layer is the view of the DataSet. No view, no selection. Several views of the same dataset - maybe several different selections. Asking a primitive whether is it selected or not is a strange concept anyway. Why should it know? In which context? Imagine a tactical overview (a small view of the complete in-memory data rendered in the screen corner) or any other auxiliary view of the same dataset. You'd like to use the same rendering code, yet you don't want it to render the selected primitives the same way, for example. So I would go even further and deprecate/remove the selection notion from the primitive altogether. It is used in few places only anyway (beyond painting) and would be well served by a selection set on the Layer anyway. Regards, Nenik PS: In case you are afraid of the memory footprint of the selection set, you can borrow the Storage class from josm-ng. It will cost around 7B per selected entry (that is pretty small unless you select everything) depending on the target load factor and allow you to remove a boolean from OsmPrimitive (costing anything between 0 and 4 bytes per OsmPrimitive in memory, depending on several factors). Many more places in JOSM would benefit from Storage anyway (String cache in OsmReader, Long-OsmPrimitive maps in the OsmReader and the MergeVisitor, ...) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] .jar file size is too big
Dirk Stöcker napsal(a): On Fri, 17 Jul 2009, Frederik Ramm wrote: Only 24% of JOSM users use english software version - The majority uses localized JOSM (50% use german). Everybody loses if languages are packaged with the bundle - the German user downloads about 3 MB of compressed translation classes when only 250 KB are relevant to him. Same for the English, Danish, Japanese, Spanish, Czech, French, and all the others. I'm not saying don't translate. I just say don't force *every* JOSM user to download *every* language which is what we currently do. Well, until someone presents an overly clever system to handle the language issue this is a yes/no question. Sorry. And I don't know other software where this is solved better. Webstart with jarindex and jars split per language? Making the josm-server more complex to build up an automatic send me translation data for my josm is also not good. I already moved too much logic into the server which will bring trouble when someone else will take over maintainership in future and has to care for that stuff. No server side logic necessary. Only build-time to split the jar according to locales and generate the right JNLP descriptor. The syntax is like: resources locale=xx_XX jar href=josm-lang-xx_XX.jar download=lazy/ /resources resources locale=yy jar href=josm-lang-yy.jar download=lazy/ /resources Nenik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [PATCH] timestamp parsedTimestamp in OsmPrimitive
Jiri Klement napsal(a): Hi, Attached patch replaces timestamp and parsedTimestamp in OsmPrimitive with DateContainer class accessible only using setter and getter. The patch is not much usefull on itself but hopefully its the first step to make OsmPrimitive encalupsed (without public variables) so things like spatial index or better caching will be possible in future. I have read both the patch and the thread and I would suggest something different, once you're touching this and removing public access to the field(s). First, adding another holder class is both unnecessary and a memory waste. You can add reasonable access methods directly to OsmPrimitive (while providing e.g. DateComparator for comparing OsmPrimitive dates, if necessary) and resort to keeping only a private integer timestamp (in seconds, not long millis) inside the OsmPrimitive. This means that you'll need to parse all the timestamps during xml parsing, but if done properly, you won't notice the slowdown. Feel free to use the parsing code from josm-ng: http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/utils/DateUtils.java which I do use quite quickly for datasets much larger that JOSM can even imagine. (I have spent quite some time benchmarking and optimizing the parsing code, you can be sure I know why there was lazy parsing and everything in the riginal code). As long as you hide the field and provide only the Date/String(/int) API, you can reintroduce the String field anytime though (but you won't need to). Regarding your: // TODO Is it enough to compare string representation? Dates can be in different format but are they in real life? No, it isn't. The timestamps seem to be stored in the OSM database in the textual form or at least keep the original timezone information (which is useless anyway) and you'll encounter many different formats (timezones) coming from the OSM server all the time (in the same download). Just download a random area, store to a file and look there. Once you're all integerized, you can remove all the String based code paths to simplify the code. Petr ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
