Re: [josm-dev] GSoC: OpenGL view for JOSM
On 10.03.2015 21:35, Michael Zangl wrote: Am 10.03.2015 um 16:42 schrieb Paul Hartmann: I would be very interested in a basic benchmark / proof of concept! Here you go. Some hours of work, and JOGl renders basic lines. To make it fair, I removed everything except the line rendering from the Java2D renderer. Wow, this was fast! To get a fair comparison, you need to turn off anti-aliasing for Java2D (or turn it on for JOGL). The JOGL phase 1 contains creating the line geometry (computing positions on screen, ordering by layer, ...). This can be cached and is a quick and dirty solution currently (some hashtables, lots of temporary objects and no nice line caps). I think I can get that down to be more like the old values, but probably not as low as those are (for a re-render. Unchanged objects could be skipped in this phase, changing of objects after zooming delayed). Phase 2 is the time required to collect all triangle buffers and send them to the graphic card (no VBOs/optimizations used at the moment, those would speed up phase 2 even more...) Now I'm curious how the code looks like. :) You can share it by forking the JOSM mirror on github and create feature branches (or simply attach diff-files). I think no one will mind if it is quick and dirty, as it is clear that this is a preliminary test. And we could move the whole benchmark topic to a new ticket on JOSM trac as it may become a longer discussion. Paul ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GSoC: OpenGL view for JOSM
On 10.03.2015 14:06, Michael Zangl wrote: Hi, Thanks for the feedback. Am 10.03.2015 um 11:22 schrieb Dirk Stöcker: And now the bigger part with the BUT: I don't think that implementing OpenGL drawing interface will be a working solution. I would disagree, this sounds like a great project for GSoC! :) * 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. 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. 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. Yes, the first goal should be to develop this as a plugin. Maybe it can be integrated in JOSM core later, but there are many ifs. Making the necessary changes to JOSM core won't be easy, you should consider this a major part of the 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? There is some benchmark output in the method StyledMapRenderer.render, that can be activated for testing. It will print lines like this to the command line: rendering phase 1 (calculate styles): 57 ms; phase 2 (draw): 129 ms This means that it took 57 ms to calculate the list of primitives to draw (ElemStyle class). Then the actual drawing (Graphics2D.drawRect and so on) took 129 ms. We did a lot of optimizations for the first phase in the past. This is exactly the reason why now the second phase, the final drawing speed, *is* really the limiting factor. If the final drawing was, for example, 30% faster, this would most definitely have a noticeable effect. 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. I would be very interested in a basic benchmark / proof of concept! For example a simple Java program that draws a few polygons (filled), icons and texts on a canvas. Ideally it would be somewhat comparable to what you typically need to draw on the JOSM map area. Then compare JOGL rendering speed with the normal Java2D calls (with OpenGL-based Pipeline enabled, i.e. -Dsun.java2d.opengl=true). What do you gain (with and without VBOs)? This is probably highly hardware dependent, but if you put the code somewhere, we could test it on other systems as well. If you find benchmarks done by other people, this could also be interesting. Without a rough estimation of the improvement, it is hard to tell if this project is worthwhile or not (for you and us)! * 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. 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 According to Wikipedia, it is possible to combine Java2D and 3D OpenGL graphics. It should be a goal to replace the performance-critical layers with OpenGL (osm-data and maybe gpx), and leave everything else untouched. * 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
Re: [josm-dev] GSoC: OpenGL view for JOSM
On 10.03.2015 20:13, Dirk Stöcker wrote: 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. It uses Java Native Interface, so it comes with a native lib for each platform and architecture (.so, .dll). You have to copy the lib to a temporary folder at plugin start and make sure it is in the Java library path. This should be possible without user intervention, so from the outside, it looks like pure Java. 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? I'm planning to mentor one project this year, but haven't decided which one. We have more students interested in JOSM-related projects than in the last years. This must be in part because good project ideas have been proposed, thanks to everyone who contributed! Paul ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
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] 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
