Re: [josm-dev] GSoC: OpenGL view for JOSM
On Mon, 9 Mar 2015, Michael Zangl wrote: This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. First: Further improving the drawing speed in JOSM is a very appreciated goal! And now the bigger part with the BUT: I don't think that implementing OpenGL drawing interface will be a working solution. * It doesn't look like Java bindings for OpenGL are something which can be considered a standard. As JOSM is cross-plattform it probably never can be integrated into the core. See e.g. PROJ4 plugin, which never will make it into core. * I doubt that the final drawing speed really is the limiting factor. We did a lot of optimizations in the last years and these mainly focused on reducing the number of displayed elements and the element access: This resulted in major speed improvements. Did you do a simple check and disable ONLY the final paint functions from drawing and check speed increase? * Your proposal contains so much, that it is impossible to get more than a study in the given time (except you are an software development magician). NOTE: A solution which does not cover the same display quality as we have now (i.e. fully support of existing style capabilities) will be unusable to us later. Instead of OpenGL a road to have more success seems to be caching approaches and display data reduction. E.g. we probably draw a lot information, which actually is not really visible (One example: in low zoom many streets will be overlayed and displayed as single points - there is actually no sense in drawing them). Also in one point I read that since the map does not change. That's actually never true. People permanently zoom and pan and change data, so there are permanent changes. * An intelligent way to only reevaluate stuff which really changed (we had already a try to use dirty marking and adapted painting, but it never got working reliable and thus finished) or * An way to do asynchronous map refresh and simple display of scaled previous state until done with the proper sectorized refresh (i.e. like for TMS/WMS) or * Whatever else clever algorithm to reduce the number of actual redraws seems a better approach for me. Regarding development: JOSM has a continous integration development model. That is largely incompatible with the idea of GSoC. This means creating a large change in the JOSM core very likely will fail afterwards. There are two alternatives: a) Developing a plugin and doing only minor core changes. A working and important plugin can then later step-by-step be integrated in the core. I can't say how easy or complicated that is with the tightly integrated drawing components, but very likely it is possible to create a small set of necessary patches to create a usable API. Finding an API which does not require permanent maintaining the plugin when core changes occur seems not so easy. b) Create a separate technology study showing the possibilities of a new approach which then cut down into pieces and patch by patch integrated. That needs a lot of additional work after the project is done, may be 5 times longer than the actual GSoc project. Are you willing to do this? Sorry, but I have not heard of you before, which is not a good sign for me. I don't know if that approach is allowed within a GSoC project. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GSoC: OpenGL view for JOSM
Hi, Thanks for the feedback. Am 10.03.2015 um 11:22 schrieb Dirk Stöcker: On Mon, 9 Mar 2015, Michael Zangl wrote: This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. First: Further improving the drawing speed in JOSM is a very appreciated goal! And now the bigger part with the BUT: I don't think that implementing OpenGL drawing interface will be a working solution. * It doesn't look like Java bindings for OpenGL are something which can be considered a standard. As JOSM is cross-plattform it probably never can be integrated into the core. See e.g. PROJ4 plugin, which never will make it into core. You are right, JOGL (which I would use) is only available for Linux, Windows and Mac. There are no real standard libraries out there. It would also be a big dependency to add it to JOSM. This is why I favor to adding it as a plugin, but there will probably changes needed to make it work. * I doubt that the final drawing speed really is the limiting factor. We did a lot of optimizations in the last years and these mainly focused on reducing the number of displayed elements and the element access: This resulted in major speed improvements. Did you do a simple check and disable ONLY the final paint functions from drawing and check speed increase? No, I did not. This would not give you the real speed improvements. Because if you really wanted to test the speed improvements, you would need to disable all drawing calls for unchanged Elements. Those elements could be cached in the GPU and would only need to be invalidated once they are changed. * Your proposal contains so much, that it is impossible to get more than a study in the given time (except you are an software development magician). NOTE: A solution which does not cover the same display quality as we have now (i.e. fully support of existing style capabilities) will be unusable to us later. This depends on what your goals are: Are you trying to replace the current view? Then yes, you need all features and full compatibility (and all plugins need to be changed, ...). Are you just adding an alternative display mode? Then it would be possible for people to use it for basic mapping, and switch to the plain java renderer when using more advanced styles. But you don't use a lane-checking style when you have a zoomed-out map. I am definitely not planing on supporting everything. There are just so many plugins and tools using their custom drawing that this would not Instead of OpenGL a road to have more success seems to be caching approaches and display data reduction. E.g. we probably draw a lot information, which actually is not really visible (One example: in low zoom many streets will be overlayed and displayed as single points - there is actually no sense in drawing them). I have done this before in a game: http://www.settlers-android-clone.com/ The background consists of a grid of tiny triangles that each get their own texture. At first we tested a lot of Java 2D, including caching, pre-rendering tiles and only displaying them, faster datastructures to render the images (like getting all geometry in a single array and just walking that array) and classic OpenGL rendering. All of this did not allow us to run smoothly on a fast graphic card. In the end, we ended up using OpenGL with VBOs. The whole Background is a single VBO in which areas get invalidated as soon as the ground changes. You can see some images on the web page to get an impression of how many stuff there is moving. Also in one point I read that since the map does not change. That's actually never true. People permanently zoom and pan and change data, so there are permanent changes. There are only a few changes per frame relative to the amount of data that is presented to the user. Even if you pan a full screen width per second, that would be 30 frames (if you want it really smooth: 60) which the current implementation renders everything, the OpenGL implementation would only need to send the new elements to the graphic card (and instruct it to render the old ones). * An intelligent way to only reevaluate stuff which really changed (we had already a try to use dirty marking and adapted painting, but it never got working reliable and thus finished) or This would be essential to use VBOs reliably. Do you have any references of what was already tried? I simply expected the DataChangedEvent to be fired every time the OSM data was changed (and adding own invalidation events for hover/active). This would handle most data that is displayed, the rest (tools, bounding boxes, ...) should not introduce much drawing overhead. * An way to do asynchronous map refresh and simple display of scaled previous state until done with the proper sectorized refresh (i.e. like for TMS/WMS) or * Whatever
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
On Mon, Mar 9, 2015 at 10:19 AM, Michael Zangl openstreet...@michael.fam-zangl.net wrote: This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. One reason is fairly simple to fix: JOSM loads background image tiles in a non-optimal order. If it first loaded the tiles under the currently selected object and the mouse cursor, it would feel much faster. As it stands often the map tiles that are half off screen come in first. ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Build Errors
Version 1.8.2 On 10 March 2015 at 15:56, Toby Murray toby.mur...@gmail.com wrote: What version of ant are you using? This seems relevant: https://josm.openstreetmap.de/ticket/10385 Toby On Tue, Mar 10, 2015 at 9:51 AM, Harvey Sama princeme.s...@gmail.com wrote: Hello. I tried to build the project using ant. I get the following error; C:\Users\Harvey\eclipseLuna\josm\build.xml:220: javac doesn't support the createMissingPackageInfoClass attribute I tried using java, but I get a list of 100 errors With eclipse, I had some JDK problem but I solved it. The application runs from eclipse and I can open the main application. Can I continue from here? -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Build Errors
Hello. I tried to build the project using ant. I get the following error; C:\Users\Harvey\eclipseLuna\josm\build.xml:220: javac doesn't support the createMissingPackageInfoClass attribute I tried using java, but I get a list of 100 errors With eclipse, I had some JDK problem but I solved it. The application runs from eclipse and I can open the main application. Can I continue from here? -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Build Errors
Thanks. It worked On 10 March 2015 at 19:33, Vincent Privat vincent.pri...@gmail.com wrote: See comment 1: https://josm.openstreetmap.de/ticket/10385#comment:1 You need at least Ant 1.8.3. 2015-03-10 16:04 GMT+01:00 Harvey Sama princeme.s...@gmail.com: Version 1.8.2 On 10 March 2015 at 15:56, Toby Murray toby.mur...@gmail.com wrote: What version of ant are you using? This seems relevant: https://josm.openstreetmap.de/ticket/10385 Toby On Tue, Mar 10, 2015 at 9:51 AM, Harvey Sama princeme.s...@gmail.com wrote: Hello. I tried to build the project using ant. I get the following error; C:\Users\Harvey\eclipseLuna\josm\build.xml:220: javac doesn't support the createMissingPackageInfoClass attribute I tried using java, but I get a list of 100 errors With eclipse, I had some JDK problem but I solved it. The application runs from eclipse and I can open the main application. Can I continue from here? -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Build Errors
See comment 1: https://josm.openstreetmap.de/ticket/10385#comment:1 You need at least Ant 1.8.3. 2015-03-10 16:04 GMT+01:00 Harvey Sama princeme.s...@gmail.com: Version 1.8.2 On 10 March 2015 at 15:56, Toby Murray toby.mur...@gmail.com wrote: What version of ant are you using? This seems relevant: https://josm.openstreetmap.de/ticket/10385 Toby On Tue, Mar 10, 2015 at 9:51 AM, Harvey Sama princeme.s...@gmail.com wrote: Hello. I tried to build the project using ant. I get the following error; C:\Users\Harvey\eclipseLuna\josm\build.xml:220: javac doesn't support the createMissingPackageInfoClass attribute I tried using java, but I get a list of 100 errors With eclipse, I had some JDK problem but I solved it. The application runs from eclipse and I can open the main application. Can I continue from here? -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Best Regards ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GSoC: OpenGL view for JOSM
On Tue, 10 Mar 2015, Paul Hartmann wrote: Well, JOGL is a (relatively) thin wrapper to access the native OpenGL libs on all major OSs. This is as cross-plattform as it gets. It's pure Java? Well, that's really a different situation, I agree. For me it looked like another bunch of external interface nobody has and want's to install. * Your proposal contains so much, that it is impossible to get more than a study in the given time (except you are an software development magician). NOTE: A solution which does not cover the same display quality as we have now (i.e. fully support of existing style capabilities) will be unusable to us later. It is ambitious, but if you stick to some core goals, I think it is possible to get something useful done in the given time. I'd nevertheless think a review of the proposal, looking at the goals and defining more focused results/targets is required. Probably you can do that, as your in-detail knowledge of that part of JOSM is better than that of anybody else. Would you be mentor? @Michael: Still comments regarding development stay the same, so that should be a plugin, but useful core changes will be accepted when necessary. We have no defined API for JOSM plugins for several reasons, main reason is that defining a proper API is much work and also needs a lot of maintenance work. Instead we use a pragmatic change when necessary approach. This means when changes are necessary to support specific plugin functions we will integrate them into core (interface functions, public/protected, ...). We won't integrate lots of code, which is unused in core (unused classes are stripped in build process anyway). That breaks plugins from time to time - a reason why we encourage opensource plugins in SVN, so we can fix them directly when broken. We also have a SVN-GitHub interface for the people who are unwilling to use SVN and require git instead. If you open a ticket describing why you want a certain code change and what it improves and attach a small patch, then chances are high you can already use that in next latest build. Bigger refactorings or changes not so easily understood or not following the established concepts will cause more discussions. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
