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)
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
