[josm-dev] Fwd: GSoC: OpenGL view for JOSM

[Michael Zangl]

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 <openstreetmap at michael.fam-zangl.net>
An: dev at 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
dev at openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev