[josm-dev] GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi,

Thanks for the feedback.

Am 10.03.2015 um 11:22 schrieb Dirk Stöcker:
> On Mon, 9 Mar 2015, Michael Zangl wrote:
> 
>> 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.
> 
> First: Further improving the drawing speed in JOSM is a very appreciated
> goal!
> 
> And now the bigger part with the BUT:
> 
> I don't think that implementing OpenGL drawing interface will be a
> working solution.
> 
> * 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. 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.

> * 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?

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.

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

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

> Instead of OpenGL a road to have more success seems to be caching
> approaches and display data reduction. E.g. we probably draw a lot
> information, which actually is not really visible (One example: in low
> zoom many streets will be overlayed and displayed as single points -
> there is actually no sense in drawing them).

I have done this before in a game:
http://www.settlers-android-clone.com/

The background consists of a grid of tiny triangles that each get their
own texture. At first we tested a lot of Java 2D, including caching,
pre-rendering tiles and only displaying them, faster datastructures to
render the images (like getting all geometry in a single array and just
walking that array) and classic OpenGL rendering. All of this did not
allow us to run smoothly on a fast graphic card.

In the end, we ended up using OpenGL with VBOs. The whole Background is
a single VBO in which areas get invalidated as soon as the ground
changes. You can see some images on the web page to get an impression of
how many stuff there is moving.

> Also in one point I read that "since the map does not change". That's
> actually never true. People permanently zoom and pan and change data, so
> there are permanent changes.

There are only a few changes per frame relative to the amount of data
that is presented to the user. Even if you pan a full screen width per
second, that would be 30 frames (if you want it really smooth: 60) which
the current implementation renders everything, the OpenGL implementation
would only need to send the new elements to the graphic card (and
instruct it to render the old ones).

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

> * An way to do asynchronous map refresh and simple display of scaled
>   previous state until done with the proper sectorized refresh (i.e. like
>   for TMS/WMS) or
> * Whatever else clever algorithm to reduce the number of actual redraws
>
> seems a better approach for me.

You seem to already have attempted that. I don't think that that will
give you a performance boost that is big enough to be noticed by the
users as good user experience. Imagine an user hovering a big background
area (residential, ...). You need to redraw the whole area. This will
delay the drawing of the hover effect a lot. No matter how fast your
rendering is afterwards, the user will always have the experience of
having a software that responds slowly if this happens every few seconds.

> Regarding development:
> 
> JOSM has a continous integration development model. That is largely
> incompatible with the idea of GSoC. This means creating a large change
> in the JOSM core very likely will fail afterwards. There are two
> alternatives:
> 
> a) Developing a plugin and doing only minor core changes. A working and
> important plugin can then later step-by-step be integrated in the core.
> I can't say how easy or complicated that is with the tightly integrated
> drawing components, but very likely it is possible to create a small set
> of necessary patches to create a usable API. Finding an API which does
> not require permanent maintaining the plugin when core changes occur
> seems not so easy.
>
> b) Create a separate technology study showing the possibilities of a new
> approach which then cut down into pieces and patch by patch integrated.
> That needs a lot of additional work after the project is done, may be 5
> times longer than the actual GSoc project. Are you willing to do this?
> Sorry, but I have not heard of you before, which is not a good sign for
> me. I don't know if that approach is allowed within a GSoC project.

I am definitely willing to give further support as soon as the project
is done. I participated in GSoC in 2012:
https://developer.pidgin.im/wiki/GSoC2012/Android

I am still in contact with some people using the java bindings for their
own projects. Although I did not need to make changes to the core
project, not even the bug-fixes from my branch were merged to main. I
gave up there after some requests. This was a bit sad to me, and I
really want to produce something usable this time. There will probably
changes needed to the JOSM core to plug into the right spots nicely and
not use dirty hacks (and avoid just copying code).

How difficult is it to get small changes/additions in main josm? What
about those two examples (not both required):
- making WMSLayer#zoomIsTooBig public
- Changing WMSLayer#paint to use the visitor-Pattern on every image in view

Michael