Re: [OSM-dev] GSoC: OpenGL view for JOSM
2015-03-19 0:01 GMT+01:00 Michael Zangl openstreet...@michael.fam-zangl.net: Am 18.03.2015 um 22:59 schrieb Wiktor Niesiobedzki: Hi Michael, Yes, I have. This already lead to two tickets ;-) (11231, 11227, both in the mapcss code). After mapcss is parsed (and then cached), most time is spend sending the paint calls of Java2D. This cannot be parallelized (in contrast to computing the OpenGL geometry and bulk-sending it afterwards). I wasn't aware of the previous discussion at josm-dev@, thanks for pointing out. 3. There is at least one 3d plugin for JOSM using OpenGL - Kendzi3D (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Kendzi3D) that I'm aware of, have you tried playing with it? No, I was not even aware of that plugin. That plugin also uses jogl to render. It is not aimed at editing the map but more at having a 3D preview of the map (like the Mapnik style is for 2D). Indeed, but from what I've heard, there was few stability issues with jogl. So it might provide some valuable input. I'll take a look at your work, it looks promising. Cheers, Wiktor ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: OpenGL view for JOSM
Hi Wiktor Am 18.03.2015 um 22:59 schrieb Wiktor Niesiobedzki: Hi Michael, Your proposal looks like it's well thought. I'm not proficient with OpenGL programming, but I'd like to ask you a few questions about your vision: 1. Do you have any benchmarks, that OpenGL / Vertex Buffer Objects outperform 2d drawing, when we need only to draw simple lines? OpenGL can draw single lines, but this is sort of deprecated. You can draw a rectangle instead (or a slightly different shape, respecting line caps). As Paul already said, I sent some benchmarks on the mailing list. You can try it yourself: https://github.com/michaelzangl/josm To compile, you need to extract the jogamp-all-platforms to your eclipse project directory. Only line drawing is implemented (and everything else is disabled in Java2D). Don't be scared by the high times for geometry computation, many normals get computed several times, point iterators converted to array lists, ... This mainly aims at testing the render time that would be possible with OpenGL. This does not use VBOs. I have experience with those from a 2D-game I made that makes heavy use of small geometry tiles. With those, there should be even more speed improvements on modern graphic cards. The main aim of this project is not to reduce the overall render time of the whole scene (although this is likely to happen) but mostly focus on reducing the render time in a way that makes the view feel responsive to the user. 2. Have you tried to profile JOSM (for example - with visualvm) and confirmed, that it's 2d API, that lacks the performance? Yes, I have. This already lead to two tickets ;-) (11231, 11227, both in the mapcss code). After mapcss is parsed (and then cached), most time is spend sending the paint calls of Java2D. This cannot be parallelized (in contrast to computing the OpenGL geometry and bulk-sending it afterwards). 3. There is at least one 3d plugin for JOSM using OpenGL - Kendzi3D (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Kendzi3D) that I'm aware of, have you tried playing with it? No, I was not even aware of that plugin. That plugin also uses jogl to render. It is not aimed at editing the map but more at having a 3D preview of the map (like the Mapnik style is for 2D). 4. There might be a lot of space for improvement, if we could early decide, whether object should be at all considered for drawing, at specific zoom level, or if we could simplify objects, that we are drawing Most of these improvements should be done in the style, not the drawing code itself. Simplification of objects might be a good option for larger drawing areas, but it would also require some sort of geometry cache. Michael Cheers, Wiktor 2015-03-09 13:58 GMT+01:00 Michael Zangl openstreet...@michael.fam-zangl.net: Hello, 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. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses
Re: [OSM-dev] GSoC: OpenGL view for JOSM
Hi Michael, Your proposal looks like it's well thought. I'm not proficient with OpenGL programming, but I'd like to ask you a few questions about your vision: 1. Do you have any benchmarks, that OpenGL / Vertex Buffer Objects outperform 2d drawing, when we need only to draw simple lines? 2. Have you tried to profile JOSM (for example - with visualvm) and confirmed, that it's 2d API, that lacks the performance? 3. There is at least one 3d plugin for JOSM using OpenGL - Kendzi3D (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Kendzi3D) that I'm aware of, have you tried playing with it? 4. There might be a lot of space for improvement, if we could early decide, whether object should be at all considered for drawing, at specific zoom level, or if we could simplify objects, that we are drawing Cheers, Wiktor 2015-03-09 13:58 GMT+01:00 Michael Zangl openstreet...@michael.fam-zangl.net: Hello, 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. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and
Re: [OSM-dev] GSoC: OpenGL view for JOSM
On 3/18/2015 2:59 PM, Wiktor Niesiobedzki wrote: 1. Do you have any benchmarks, that OpenGL / Vertex Buffer Objects outperform 2d drawing, when we need only to draw simple lines? 2. Have you tried to profile JOSM (for example - with visualvm) and confirmed, that it's 2d API, that lacks the performance? He did some basic benchmarks of line-drawing which he posted to the josm-dev list: https://lists.openstreetmap.org/pipermail/josm-dev/2015-March/007275.html The differences are pretty impressive, going from a 14s draw to a 6s draw for a big area and 600ms to 300ms for a small area. There's also reason to believe that the times could be brought down to about 10%-20% of the existing 2d implementation. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC: OpenGL view for JOSM
Hello, 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. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and color, closed or open. -- Draw a filled area (without contour) -- Add text at a given position. -- MapCSS properties this basically supports: width, color (rgba), dashes, linecap, linejoin, fill-color (rgba), font-size, text-color, text-offset, text. -- What we won't support: z-index (but we could order the elements before drawing), casing, extrude, icons, text-position. - Each VBO is tied to map objects that it depends on. That way, it only needs to be updated if those objects change. Doing this is done by the renderer (which also has knowledge of all MapCSS styles). -- The MapCSS renderer needs to be adjusted to keep track of object changes and re-create a VBO as soon as it's rules change. Implementation schedule (12 weeks until pencils down) 2 Weeks: Getting to know JOSM and adding the OpenGL view to the core (and an interface to use it). 2 Weeks: Adding the OpenGL interfaces we need (like computing the OpenGL-Coordinates for a point on earth and the
