libosmscout icon indicating copy to clipboard operation
libosmscout copied to clipboard

PoC: Add initial support for node specific render data caching in MapPainterQt.

Open Framstag opened this issue 9 years ago • 2 comments

To evaluate the effect of caching of render specific data in regard to render performance and memory consumption an initial proof of concept should be done:

  • Add another Draw method that either gets concrete tiles passed or the MapService (so it can request tiles on demand itself).
  • Implement a cache, that allows assignment of one or one per object type structs to a tile id in the cache.
  • Implement a simple API to allow a specific renderer to extend the data stored for an object type by its own custom information.
  • Create one or multiple data objects for caching as much as possible information for a node. Such information could be: One or multiple resolved label and symbol styles including label data, dimensions and positions.

In the first step Information should be stored projection on on-screen position independent. Before drawing only the following steps should be required to be done:

  • Transform geo location of the node to an on screen coordinate
  • Evaluate the label in relation to other labels resulting in "visible" or "not visible"

In a second step one could already evaluate visibility based on the other labels within the same tile.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Framstag avatar Jun 25 '16 16:06 Framstag

@Karry What is your opinion, is this really necessary? It would cost additional memory and IMHO the renderer is currently fast enough?

Framstag avatar Jun 15 '19 16:06 Framstag

All primitive transformations, label layouting, sorting of areas (...) is done again and again for every rendering. There is place for improvements definitely, rendering may take more than second in dense areas. But the bad UX may be compensated by canvas transformations (or tile transformations) as implemented in Qt MapWidget. So I don't see this as priority right now.

I guess that OpenGL painter may help here and question is if we should invest energy to improve it, instead of optimizing software renderers...?

It is up to you, if you want to keep this issue open as an idea for improvement...

Karry avatar Jun 18 '19 05:06 Karry