[OSM-dev] GSoC: OpenGL view for JOSM

Wed Mar 18 21:59:04 UTC 2015

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 <openstreetmap at 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
> 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
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev