Improve / refactor drawing priorities system #4314

New issue

Open

opened 2023-01-21 16:11:28 +00:00 by pastk · 5 comments

pastk commented

2023-01-21 16:11:28 +00:00

Owner

The current system used to prioritize what is drawn over what (i.e. what is first, second, etc.) is overly sophisticated, hard to debug and not transparent / confusing for style designers.

Let's try to improve on it.

The first step is to document how it works as a whole system now and collect the biggest shortcomings / nuisances.
After that we can try design a better system.

The current system used to prioritize what is drawn over what (i.e. what is first, second, etc.) is overly sophisticated, hard to debug and not transparent / confusing for style designers. Let's try to improve on it. The first step is to document how it works as a whole system now and collect the biggest shortcomings / nuisances. After that we can try design a better system.

👍 2

RedAuburn commented

2023-01-21 16:29:17 +00:00

Member

simplifying drule files by adding metatypes like all, nodearea, nodeline etc would be good (organicmaps/organicmaps#4137)

i'll see what else i can think of 👍

simplifying drule files by adding metatypes like all, nodearea, nodeline etc would be good (https://git.omaps.dev/organicmaps/organicmaps/issues/4137) i'll see what else i can think of 👍

pastk commented

2023-01-21 16:38:13 +00:00

Author

Owner

From a style designer's POV priorities are set via integer z-index properties in mapcss style files.

Here a few pain points:

When styles are compiled (into protobuff files) z-index values are changed completely (as they're "compressed" into a smallest possible integer range) so there is no way to establish a link between the original and compiled value. It makes debugging priorities much harder as one doesn't really know if the right/expected value is used in compiled files or not.
Another nasty consequence is that a change in z-index of just one type can lead to change of all compiled priority values.
z-index values could be overriden in mapcss files (sometimes by mistake) and its hard to find what value is in actual use (because of 1.)
There are modifiers (fill-position: background) and hacks (-x-me-text-priority, -x-me-min-text-priority, -x-me-icon-priority, etc.) that change z-index values further making it even harder to understand what has a priority over what.
A higher original z-index or even compiled priority value doesn't mean the feature will be drawn on top of a lower value feature, because those priority values are not used as primary priorities by the renderer. Instead there are several rendering "layers", e.g. area fills, lines, icons, text labels and layer modifiers also. Thus style-set priority values have effect inside these rendering layers only.
Priorities could be treated differently in different rendering layers. E.g. for area fills a better approach would be to draw enclosed (inside, smaller) features over the enclosing (outside, bigger) ones regardless of their priority, see #2170.
Icons/labels displacement mechanism uses other factors (e.g minVisibleScale and maybe something else, need to check the code) first before resorting to style-set priorities. Hence a POI with a higher z-index could be displaced by a lower z-index POI still, e.g. see #2318.
There is a parallel priority system used to determine what name/description to display in PP for a POI with multiple OM types (e.g. a shelter and a bench), it ignores style-set values completely, see organicmaps/organicmaps#1392 (comment). Thus it adds more confusion and complexity.

update1: added point 7.
update2: expanded point 1.

From a style designer's POV priorities are set via integer `z-index` properties in mapcss style files. Here a few pain points: 1. When styles are compiled (into protobuff files) `z-index` values are changed completely (as they're "compressed" into a smallest possible integer range) so there is no way to establish a link between the original and compiled value. It makes debugging priorities much harder as one doesn't really know if the right/expected value is used in compiled files or not. Another nasty consequence is that a change in `z-index` of just one type can lead to change of all compiled priority values. 2. `z-index` values could be overriden in mapcss files (sometimes by mistake) and its hard to find what value is in actual use (because of 1.) 3. There are modifiers (`fill-position: background`) and hacks (`-x-me-text-priority`, `-x-me-min-text-priority`, `-x-me-icon-priority`, etc.) that change `z-index` values further making it even harder to understand what has a priority over what. 4. A higher original `z-index` or even compiled priority value doesn't mean the feature will be drawn on top of a lower value feature, because those priority values are not used as primary priorities by the renderer. Instead there are several rendering "layers", e.g. area fills, lines, icons, text labels and `layer` modifiers also. Thus style-set priority values have effect inside these rendering layers only. 5. Priorities could be treated differently in different rendering layers. E.g. for area fills a better approach would be to draw enclosed (inside, smaller) features over the enclosing (outside, bigger) ones regardless of their priority, see #2170. 6. Icons/labels displacement mechanism uses other factors (e.g minVisibleScale and maybe something else, need to check the code) first before resorting to style-set priorities. Hence a POI with a higher z-index could be displaced by a lower z-index POI still, e.g. see #2318. 7. There is a parallel priority system used to determine what name/description to display in PP for a POI with multiple OM types (e.g. a shelter and a bench), it ignores style-set values completely, see https://git.omaps.dev/organicmaps/organicmaps/issues/1392#issuecomment-1026112040. Thus it adds more confusion and complexity. update1: added point 7. update2: expanded point 1.

pastk commented

2023-01-21 16:41:58 +00:00

Author

Owner

simplifying drule files by adding metatypes like all, nodearea, nodeline etc would be good (#4137)

i'll see what else i can think of +1

I'll start a new broader ticket about styles refactoring shortly.
Let's keep this one focused on priorities only (as its a big enough thing to discuss separately and it touches many parts of the system, not just mapcss style files syntax.)

> simplifying drule files by adding metatypes like all, nodearea, nodeline etc would be good (#4137) > > i'll see what else i can think of +1 I'll start a new broader ticket about styles refactoring shortly. Let's keep this one focused on priorities only (as its a big enough thing to discuss separately and it touches many parts of the system, not just mapcss style files syntax.)

👍 1

pastk commented

2023-01-22 09:19:00 +00:00

Author

Owner

@vng @biodranik @dvdmrtnz

biodranik commented

2023-01-28 13:03:16 +00:00

(Migrated from github.com)

Can we avoid using any explicit numbers at all? E.g. can we simply use the style's order (line number) in the file?

If layering makes sense and is required, can we split style files by layers? Will it simplify styles definition?

Can we avoid using any explicit numbers at all? E.g. can we simply use the style's order (line number) in the file? If layering makes sense and is required, can we split style files by layers? Will it simplify styles definition?

This repo is archived. You cannot comment on issues.