Modify

Opened 2 years ago

Last modified 11 months ago

#16733 assigned enhancement

Try offline transcoding of SVG icons using Photon

Reported by: Don-vip Owned by: simon04
Priority: major Milestone: Longterm
Component: Core Version:
Keywords: svg performance Cc: stoecker, simon04, floscher, michael2402, wiktorn, Klumbumbus

Description

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.

Attachments (3)

16733.patch (14.2 KB) - added by simon04 11 months ago.
img_osmbasedmap.java (244.2 KB) - added by simon04 11 months ago.
16733-v2.patch (30.4 KB) - added by simon04 11 months ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 2 years ago by 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.

comment:2 Changed 2 years ago by 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.

comment:3 in reply to:  2 ; Changed 2 years ago by 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.

comment:4 in reply to:  3 Changed 2 years ago by 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.

comment:5 Changed 2 years ago by 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.

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by Don-vip

It would avoid problems like #16838.

comment:8 in reply to:  7 Changed 2 years ago by 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.

comment:9 Changed 2 years ago by 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 :)

Changed 11 months ago by simon04

Attachment: 16733.patch added

Changed 11 months ago by simon04

Attachment: img_osmbasedmap.java added

comment:10 Changed 11 months ago by simon04

Milestone: Longterm
Owner: changed from team to simon04
Status: newassigned

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.

comment:11 Changed 11 months ago by 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.

Changed 11 months ago by simon04

Attachment: 16733-v2.patch added

comment:12 Changed 11 months ago by 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>

comment:13 in reply to:  12 ; Changed 11 months ago by 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.

comment:14 in reply to:  13 ; Changed 11 months ago by 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

comment:15 in reply to:  14 Changed 11 months ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain simon04.
as The resolution will be set.
to The owner will be changed from simon04 to the specified user.
The owner will change to Don-vip
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.