osd: Allow "remaining space" size specifier

[aerostitch]

Issue migrated from trac ticket # 1255

component: gui/internal | priority: major

2014-09-28 04:57:49: @mvglasow created the issue

---

It would be helpful to be able to specify "remaining space" as the size for an OSD item. A use case would be a combination of one fixed-width OSD item in one corner (e.g. navigation_next_turn) and another one next to it (e.g. text announcing the road following the maneuver), which fills the remaining screen width and can thus adapt to changes in screen size, e.g. when the display is rotated.

Syntax could be something like this: <osd enabled="yes" x="100" y="0" w="-150" h="50" />

Negative pixel values for width would mean "screen width minus the indicated number of pixels". The example above would be an item occupying the entire width of the screen, minus 150 pixels. Placing it at 100 pixels would leave a margin of 100 pixels on the left and 50 on the right.

The same logic would apply to negative heights.

An optional extension could be something like: <osd enabled="yes" x="10%" y="0" w="90%-100" h="50" />

Here the width is a percentage minus a pixel value, which would be interpreted to mean "90% screen width minus 100 pixels". In this example the item is placed at 10%, leaving 10% of the screen width as a margin on the left and 100 pixels on the right.

[aerostitch]

2015-01-03 05:09:41: tryagain commented

---

Since 5989 we support negative values for w and h attributes.

Have not implemented the logic for "90%-100" - like expressions.

It could be possible to do it if we shorten range for possible values. Currently we have 31 bits to express absolute values ranging from -0x40000000 to 0x3fffffff, mapped directly to the same value of u.num and 30 bits to express percent values -0x20000000 to 0x1fffffff, mapped to values of u.num 0x40000000 to 0x7fffffff. So we have unused 30-bit space from -0x40000001 to -0x7fffffff, which could be used to hold two values at the same time, one for absolute value, another for percent one. If we give 20 bits to the signed absolute value part, and 10 bits to sthe signed percent value, we'll be able to represent -524288 to 524287 of absolutes, and -512 to 511 of percents. Looks like sufficient for screen purposes.

Possibly-relative attributes attr_x and attr_y are now also widely [ab]used to hold geographical coordinates, but seem in that case to always be interpreted as absolute values.

Another drawback is rounding errors. If we want to have three osds of 10% width glued by their sides with another item of 70% width, we have to calculate last item width as "whole - 3round(whole10%)" rather than "round(whole*70%)", because of rounding errors. To implement this, i think we'll have to accept arbitrary expression for width/height/coordinates, but it seems to be impossible to fit this into single 32bit integer.