Hi, I'm also posting this on the JOSM-List in hope to get feedback on the technical parts here.
Regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: [OSM-dev] GSoC: OpenGL view for JOSM Datum: Mon, 09 Mar 2015 13:58:41 +0100 Von: Michael Zangl <openstreet...@michael.fam-zangl.net> An: d...@openstreetmap.org 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 objects it should render). 3 Weeks: Create a VBO drawing library. 3 Weeks: Add a mappaint style renderer (hopefully being able to use as much of an existing renderer as possible). Make objects clickable. Bonus (I can't tell if I have time, but basically this should be the same as any other observed object changes): Support hover and active. 2 Weeks: (to be discussed which): Add a new render layer for background images. It should then be possible to draw a GeorefImage list and e.g. the Bing map. Main challenges: - Prevent code-duplication as much as possible. - Get the OpenGL-Part as stable as possible (not fully featured, but non-crashing), so that it can be included in trunk after GSoC is over. To be discussed: - How much of this can be a plugin? Is it possible to use a plugin for all of this or should as much of it be in core? I would suggest adding the basic OpenGL stuff to Core and implementing the layer renderers as plugins. That way, each of them can be improved independently. - Should the layer Painters be a private for to each layer (and provided by it) or should they be provided by a central system (get me the Painter for ...) - Use shaders for the background images. - I did not find an OpenGL MapCSS renderer. This could be a nice project to have (for other editors, smartphones, ...). Are there any efforts currently? We don't need to do things twice... - Should we support multiple renderers? I really opt for this, we could e.g. add a mini-map to the sidebar to show where you are on the map or even support opening multiple Edit-Windows (imagine having the official Map with house numbers on one screen and the map with Bing sattelite on the other, house number mapping would just get so much easier ;-)) What are your thoughts on this? In hope of a lot of feedback, Michael Zangl _______________________________________________ dev mailing list d...@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev