[josm-dev] GSoC: OpenGL view for JOSM

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

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

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.

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

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.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)