Try offline transcoding of SVG icons using Photon

[Don-vip]

As we move from PNG icons towards SVG icons in #15240 we suffer inevitable performance penalty in UI/map rendering showing these icons.

I just discovered the ​Photon library which sounds very promising. It allows to "compile" SVG icons to Java classes which draw SVG icons directly using Java2D draw calls:

Photon transcoder allows you to convert an SVG source into a corresponding Java class that contains a sequence of matching Java2D canvas draw calls to render the original content.

We should try it and measure the performance impact.

[stoecker]

Where do you think that would help? We already convert to bitmap and cache the bitmap.

If really an issue to increase speed we could save the bitmap cache on disk.

[michael2402]

I just had a look at the source of that library.

The library uses the org.apache.batik.bridge.GVTBuilder to translate an image from SVG to Java2D primitives. So far, so good.

But instead of e.g. serializing those objects, the library generates source code from them (which is then converted to byte codes).

The automated source code generation seems pretty primitive. As far as I can tell, it is not incremental (which would improve build times a lot). It might however be possible to use Batik directly (at compile time or at runtime and then caching).

Rendering times might be improved significantly using this library, because it paints primitives instead of bitmaps. And memory consumption would be reduced for high-resolution icons.

[stoecker]

Replying to michael2402:

Rendering times might be improved significantly using this library, because it paints primitives instead of bitmaps. And memory consumption would be reduced for high-resolution icons.

Please explain. Why should drawing multiple primitives be faster than displaying a bitmap? Primitives involve logic, bitmaps are mainly a copy process.

[michael2402]

Replying to stoecker:

Please explain. Why should drawing multiple primitives be faster than displaying a bitmap? Primitives involve logic, bitmaps are mainly a copy process.

It depends on the size of the primitives and the number of features. In general, displaying a bitmap is only a copy process if the bitmap both is non-transparent and drawn in it's original size. Painting primitives has the following advantages:

• You don't need to render non-transparent parts of the image
• You can use OpenGL-Accelleration (not for our map-rendering since we render onto a bitmap, but for buttons)
• Filtering involves less computations (e.g. converting to grayscale)

For a 16x16px icon, I would imagine the icon drawing to be faster than multiple primitives.

[stoecker]

Hmm. Overlaying bitmaps including transparency was extremely fast already on Amigas in the 80ies, whereas everything vector-based was much work. If this changed then something would be very wrong with the way bitmaps are handled nowadays.

[michael2402]

Technology has changed ;-)

Overlaying Bitmaps the way the Amigas did it is still as fast (or slow) as back then. But we now have faster technologies (bulk copy operations, better floating point computations, OpenGL, ...), so that other drawing methods have gotten much faster.

You won't notice the difference in JOSM much. But for more "modern" applications that use bigger icons on a high-resolution screen, you will see a difference.

[Don-vip]

It would avoid problems like #16838.

[stoecker]

Replying to Don-vip:

It would avoid problems like #16838.

How? We can't drop SVG support, as it is required for non-internal images. So we could not simply ignore SVG parsing errors.

[Don-vip]

only for internal images I meant. I agree we must keep SVG support, I just sent a PR to svgSalamander and working on a new one :)

[simon04]

This library looks promising!

The current released version 2.5.1 lacks support for recursive transcoding. I've opened a PR for this feature against 3.0-SNAPSHOT, ​https://github.com/kirill-grouchnikov/radiance/pull/248

(When switching between 2.5.1 and 3.0 notice the incompatible package layout due to ​https://github.com/kirill-grouchnikov/radiance/commit/cb22d2ca7afd49b1f1b1b2c0dcb40c313d01e213)

🚀 I successfully plugged the transcoded images into ImageProvider / ImageResource, see attachment:16733.patch​​

I found and fixed a g.rotate(NaN) bug: ​https://github.com/kirill-grouchnikov/radiance/pull/249

A few images result in Java classes which cannot be compiled due to "java: code too large", see attachment:img_osmbasedmap.java​​ for an example. → ​https://github.com/kirill-grouchnikov/radiance/issues/250

I'll definitively do more testing. I'll investigate whether ImageResource#imgCache is needed at all for those images.

[stoecker]

Please before continuing on this ticket answer the question of the "why"? There was not no answer to that yet. What is the advantange of hardcoded icons support over the generic approach we have now if in the end we then will have to support two approaches instead of one.

[simon04]

My hope is to get rid with the nasty SVG parsing, rendering, wasteful data structures. I spent hours optimizing svgsalamander in #18749 and there's a bunch of additional patches on my computer.

---

attachment:16733-v2.patch​​ wires the transcoded icons with the map rendering (via MapImage) as well as Action icons. The transcoding has been performed using this snapshot: ​https://github.com/kirill-grouchnikov/radiance/commit/4c08c280ea78833b938726c971cfbd47333e1c6a

This patch drops the pre-rendered raster graphics. This has negative impacts on the rendering performance as can be seen from MapRendererPerformanceTest:

// r16205
<measurement><name>all draw (ms)</name><value>75.0</value></measurement>
<measurement><name>icon draw (ms)</name><value>64.0</value></measurement>
<measurement><name>symbol draw (ms)</name><value>71.0</value></measurement>
<measurement><name>node_text draw (ms)</name><value>62.0</value></measurement>
<measurement><name>line draw (ms)</name><value>71.0</value></measurement>
<measurement><name>line_text draw (ms)</name><value>70.0</value></measurement>
<measurement><name>area draw (ms)</name><value>64.0</value></measurement>
<measurement><name>big generate (ms)</name><value>42.0</value></measurement>

// 16733-v2.patch​
<measurement><name>all draw (ms)</name><value>231.0</value></measurement>
<measurement><name>icon draw (ms)</name><value>224.0</value></measurement>
<measurement><name>symbol draw (ms)</name><value>223.0</value></measurement>
<measurement><name>node_text draw (ms)</name><value>222.0</value></measurement>
<measurement><name>line draw (ms)</name><value>223.0</value></measurement>
<measurement><name>line_text draw (ms)</name><value>222.0</value></measurement>
<measurement><name>area draw (ms)</name><value>220.0</value></measurement>
<measurement><name>big generate (ms)</name><value>47.0</value></measurement>

[stoecker]

Replying to simon04:

My hope is to get rid with the nasty SVG parsing, rendering, wasteful data structures.

But we WONT get rid of it. We need to support SVG.

If it's only about the SVG data structures. Why not simply drop them from memory? We only need the rasterized images. The SVG structures are probably only kept to make rerendering with another size easier. But that will be very seldom, so that for this case rendering from scratch is probably acceptable.

[simon04]

Replying to stoecker:

But we WONT get rid of it. We need to support SVG.

True, we cannot drop sVG support. However, we can try to find an efficient way to load/compile the 929 SVG images of JOSM core.

If it's only about the SVG data structures. Why not simply drop them from memory?

This is a promising orthogonal approach. It requires some refactoring -- currently, there are (at least) four levels of map image handling/storage in place: svgSalamander/SVGUniverse, ImageProvider, ImageResource, MapImage

[stoecker]

Replying to simon04:

Replying to stoecker:

But we WONT get rid of it. We need to support SVG.

True, we cannot drop sVG support. However, we can try to find an efficient way to load/compile the 929 SVG images of JOSM core.

If it's only about the SVG data structures. Why not simply drop them from memory?

This is a promising orthogonal approach. It requires some refactoring -- currently, there are (at least) four levels of map image handling/storage in place: svgSalamander/SVGUniverse, ImageProvider, ImageResource, MapImage

ImageProvider and ImageResource aren't different places. They represent different aspects and work together.

[stoecker]

Working fine for years as is.