[josm-dev] GSoC: Improving the UI response time by using OpenGL.
osm-peda at won2.de
Sat Aug 22 10:15:35 UTC 2015
Michael Zangl schrieb:
> I have finished my GSoC project. The aim was to improve the UI response
> time by using OpenGL instead of Java2D for drawing.
your work is quite impressive! It's also really easy to install and use.
I like the improvements in regard to responsiveness but I'm afraid it's
not ready for a day-to-day use for my case (see below).
> Feel free to test, report issues and give feedback.
> Due to the geometry cache you might need to give JOSM some more memory
> when loading big data sets.
I'll tell you about my observations (limiting to bugs/oddities):
* is there a memory leak? After several minutes zooming, moving,
working,.. I get an oome (32gb ram, defaults for vm, I guess 8gb)
* if I move the map sometimes a bunch of elements are not moved at
first and it takes several seconds until they are (UI is responsive)
* the opengl-Button should be some toggle button. Currently I can't tell
from the button if opengl is enabled or not
* zoom is slow. If i move and not all stuff is moved at first, the UI
still stays responsive. If I zoom the UI is unresponsive until the
scene rendering is finished. This is annoying and much worse as with
The deal-breaker for me is the slow zoom. It's kind of a tradeoff:
really fast moving and slow zoom vs. slow moving and faster zoom. And as
I tend to move the map when I'm zoomed in and use zoom a lot to either
get a quick overview or for large movements (zoom out and in again), the
OpenGL-pipeline does not give me an advantage right now. But I'm
wondering why that is, as you noted
> [...] but moving
> the map, zooming and minor changes like hovering, selecting or moving
> one primitive are faster.
So zoom is fast for you (You didn't note it in your performance
comparison)? Any ideas on that? I have a RadeonHD 6670 with Opensource
Gallium stack, if that matters. And I'll test it on a intel hd 4xxx next
week for comparison.
More information about the josm-dev