[josm-dev] GSoC: OpenGL view for JOSM

Paul Hartmann phaaurlt at gmail.com
Tue Mar 10 15:42:07 UTC 2015


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 "if"s.

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 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.

Just as a pointer, there is a method OsmPrimitive.clearCachedStyle(), 
which invalidates the style cache, whenever the primitive (or it's 
parent / child) changes. You may be able to build on that.

> How difficult is it to get small changes/additions in main josm? What
> about those two examples (not both required):

Not too difficult in general, but the rendering code is probably not the 
easiest part to change within a short time frame. It is comprehensive 
and works in multiple interacting layers. Not impossible, just a fair 
warning. :)

Of course it depends a bit how deep you want to hook into the current 
process. In general, it shouldn't really be necessary to deal with 
MapCSS directly. The current code generates a collection of ElemStyle 
objects, which each represent one painting primitive (line, area, icon, 
...).
The method ElemStyle.paintPrimitive will draw it, but it delegates the 
basic painting to a painter (StyledMapRenderer object).

This StyledMapRenderer object is where you can jump in: It offers basic 
painting methods like "drawArea" or "drawTextOnPath", where all the Java 
2D calls are encapsulated. By changing / overriding the 
StyledMapRenderer class, you should be be able to replace the 
Graphics2D... calls with an OpenGL implementation.

Alternatively, you could also ignore most of the current code and 
implement your own AbstractMapRenderer from ground up (like it is done 
in WireframeMapRenderer). To activate it from a plugin, simply call

MapRendererFactory.getInstance().activate(MyMapRenderer.class);

> - making WMSLayer#zoomIsTooBig public

No problem.

> - Changing WMSLayer#paint to use the visitor-Pattern on every image in view

Sounds okay, but I can only judge the final patch.


Paul



More information about the josm-dev mailing list