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