Opened 10 years ago

Closed 7 years ago

#983 closed defect/bug (fixed)

Percent width for osd type text items is not recognized

Reported by: Owned by: KaZeR
Priority: minor Milestone: version 0.5.1
Component: core Version: git master
Severity: normal Keywords: size, xml, osd, patches
Cc: sebastian.leske@…,, (2)


  • Navit version: navit-svn-4863
  • Device: Samsung Galaxy Tab P1000
  • OS: Android 2.2
  • latest map from map extractor

As described at The sizes of each item can be explicitly set in pixels or percent (of screen width/height)

The problem is that only absolute width specified in pixels is working. If width is set as percent, the item id drawn with fixed size, which seems to be about 60 pixels. This is the xml configuration that doesn't work:

   <osd x="50" y="-400" w="100%" h="40" type="text" label="w is 100%" font_size="200" align="0" osd_configuration="1" />
   <osd x="50" y="-350" w="20%" h="40" type="text" label="w is 20%" font_size="200" align="0" osd_configuration="1" />
   <osd x="50" y="-300" w="60" h="40" type="text" label="w is 60" font_size="200" align="0" osd_configuration="1" />
   <osd x="50" y="-250" w="90" h="40" type="text" label="w is 90" font_size="200" align="0" osd_configuration="1" />

See the bottom-left fields from attached screenshot

Attachments (2)

width.png (67.0 KB) - added by 10 years ago.
osd item size
trac983.patch (2.9 KB) - added by mvglasow (2) 7 years ago.
Patch: Handle percentage sizes for OSD elements

Download all attachments as: .zip

Change History (23)

Changed 10 years ago by

osd item size

comment:1 Changed 10 years ago by sleske

I can confirm this on Linux (rev.4865), so it's probably not platform-specific.

I tested with an OSD scale:

<osd enabled="yes" x="30" y="-100" w="80%" h="40" 
font_size="200" type="scale" use_overlay="1"/>

In my case the scale is not rendered at all; if I replace "80%" by "80" it does get rendered (80px wide).

It might be that percentage width/height is simply not implemented. I'll try to check, and correct the Wiki as necessary.

comment:2 Changed 10 years ago by sleske

  • Cc sebastian.leske@… added

comment:3 Changed 10 years ago by sleske

I've started investigating this. The reason that width as percent does not work is that relative sizes for OSD items are (apparently) implemented in osd_std_calculate_sizes (osd.c). However, osd_std_calculate_sizes is only used as a "resize callback" (osd_item.resize_cb), so it seems it only gets called when the window is resized.

On Linux, using internal gui and "<graphics type="gtk_drawing_area"/>", the OSD scale item above does get drawn correctly after I resize the window.

I'm still trying to figure out how relative sizes are supposed to work without resizing... or maybe this just never worked :-/.

Also, if I use the example from the bug report (the text boxes), they get resized correctly on resizing the window, but the text is totally messed up. Seems the text is not resized correctly... maybe I'll file a seperate bug for that. So there's still some work to do.

Last edited 10 years ago by sleske (previous) (diff)

comment:4 Changed 10 years ago by korrosa

Also see #990.

comment:5 Changed 10 years ago by sleske

Just committed a partial fix in .

It simply adds a call during OSD setup, to the same code that is called when the window is resized. With this change, the OSD elements from the bug report (and my scale example above) are shown correctly on startup.

However, there are still some problems:

  • The text boxes with percentage width are totally messed up if the window is resized. Oddly enought, they are fine once the old size is restored by resizing back to exactly the original window size. Apparently there's some resizing bug there. The text boxes with absolute width work fine.
  • At least for buttons, percentage values only work if use_overlay="1" is used. However, with use_overlay="1" transparent icons are rendered without transparency (quite ugly).

I'll look into this, and maybe open additional bug reports.

comment:6 Changed 10 years ago by martin bruns

Unfortunately rev. 4918 is broken on Linux and Android, it crashes on both systems. Did you run it on those Systems or are you testing it with a different system.

comment:7 Changed 10 years ago by sleske

Sorry if I introduced a bug. I tested on Linux, and for me it did not crash. Anyway, my change has already been reverted (rev.4923).

To martin bruns and tegzed:

Could you add test cases to this bug, about the problems my patch introduced? Both the crash and the broken OSD layouts. I'd like to continue working on this, and testcases would be helpful.

comment:8 Changed 10 years ago by tegzed

Hi Sleske,

No problem. I suspect that osd_std_calculate_sizes() is called too early. Maybe it is triggering osd redraw and the graphics context parameters of draw_text is not yet initialized. I tested it with compass odometer,and stopwatch, all of them seems to be affected. A backtrace with odometer is pasted below. A full backtrace if pasted also: I hope this helps resolving the problem.

Bye Dandor

(gdb) bt
#0  0x00000000004259b0 in graphics_draw_text (this_=0xac12be0, gc1=0x0, gc2=0x0, font=0xac104e0, text=0xac130d0 "D:7475m ; S:0 00:00:00 0.000 m/s2", 
    p=0x7fffffffc650, dx=65536, dy=0) at graphics.c:728
#1  0x00007ffff0a489f6 in draw_multiline_osd_text (buffer=0x7fffffffc790 "D:7475m ; S:0 00:00:00 0.000 m/s2", osd_item=0x8300670, curr_color=0x0)
    at osd_core.c:646
#2  0x00007ffff0a49228 in osd_odometer_draw (opc=0x8300670, nav=0x8230400, v=0x8306670) at osd_core.c:767
#3  0x00000000004412ab in osd_std_calculate_sizes (item=0x8300670, priv=0x8300670, w=700, h=700) at osd.c:147
#4  0x0000000000441c8f in osd_set_std_graphic (nav=0x8230400, item=0x8300670, priv=0x8300670) at osd.c:335
#5  0x00007ffff0a4962e in osd_odometer_init (opc=0x8300670, nav=0x8230400) at osd_core.c:866
#6  0x000000000041ae63 in callback_call (cb=0x8300ad0, pcount=1, p=0x7fffffffcb80) at callback.c:178
#7  0x000000000041b0cd in callback_list_call_attr (l=0x822fbd0, type=attr_graphics_ready, pcount=1, p=0x7fffffffcb80) at callback.c:219
#8  0x000000000041b269 in callback_list_call_attr_args (cbl=0x822fbd0, type=attr_graphics_ready, count=1) at callback.c:235
#9  0x0000000000430e85 in navit_handle_resize (this_=0x8230400, w=700, h=700) at navit.c:333
#10 0x00007ffff0c6fa4b in gui_internal_resize (data=0x82fc110, w=700, h=700) at gui_internal.c:5934
#11 0x000000000041ae42 in callback_call (cb=0x831a700, pcount=2, p=0x7fffffffce30) at callback.c:175
#12 0x000000000041b0cd in callback_list_call_attr (l=0x8236940, type=attr_resize, pcount=2, p=0x7fffffffce30) at callback.c:219
#13 0x000000000041b269 in callback_list_call_attr_args (cbl=0x8236940, type=attr_resize, count=2) at callback.c:235
#14 0x00007ffff62904a1 in graphics_opengl_idle (data=0x0) at graphics_opengl.c:1586
#15 0x00007ffff792823b in ?? () from /lib/x86_64-linux-gnu/
#16 0x00007ffff7926a5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/
#17 0x00007ffff7927258 in ?? () from /lib/x86_64-linux-gnu/
#18 0x00007ffff7927792 in g_main_loop_run () from /lib/x86_64-linux-gnu/
#19 0x00000000004178cc in event_glib_main_loop_run () at event_glib.c:34
#20 0x0000000000421c99 in event_main_loop_run () at event.c:38
#21 0x000000000040e5ad in main_real (argc=1, argv=0x7fffffffe2b8) at start_real.c:223
#22 0x000000000040dd14 in main (argc=1, argv=0x7fffffffe2b8) at start.c:25

comment:9 Changed 10 years ago by tegzed

Here are some problemmatic osd elements:

<osd enabled="yes" type="odometer" w="350" h="40"  x="30" y="200"   font_size="450" label="D:${distance} ; S:${avg_spd}" name="odo1" auto     save_period="150"  />
<osd enabled="yes" type="odometer" w="500" h="40"  x="30" y="300"   font_size="450" label="D:${distance} ; S:${avg_spd} ${time} ${acceler     ation}" name="odo2" />
<osd enabled="yes" type="stopwatch" w="150" h="40"  x="30" y="250"   font_size="450" />

comment:10 Changed 10 years ago by sleske

Thanks for the details, I'll have a look. Hope I find something out...

comment:11 Changed 8 years ago by sleske

Similar problem: #1098, "relative positon (eg x=30%) of osd icons not working".

comment:12 Changed 8 years ago by usul

  • Keywords xml osd added
  • Milestone set to version 0.5.1
  • Priority changed from major to minor

Ok, so this issue seems to be still uptodate.

I will schedule this for the hotfix as this is a inconsistency that might confuse designers.

comment:13 Changed 7 years ago by mvglasow (2)

  • Severity set to normal

Just realized #1256 is a duplicate of this ticket. I'll close the other.

comment:14 Changed 7 years ago by mvglasow (2)

  • Cc (2) added

BTW, the issue is still there. On Android, the size issue is still there after rotating the screen. However, on Linux, resizing the window causes the OSD item to display at the correct size.

If I find the time I'll take a look at it. Maybe we just need to simulate a resize event upon creation of the OSD.

comment:15 Changed 7 years ago by mvglasow (2)

Digging into this issue a bit deeper, I see that a fix was attempted in r4918. The fix did something similar to what I had mentioned above, introducing a call to osd_std_calculate_sizes in osd_set_std_graphic in osd.c. However, the commit message for r4923 states that it reverted r4918 because it broke some OSDs. What exactly were the side effects?

I do see that, as of r4899, osd_set_std_graphic includes a call to graphics_overlay_new, passing item->w and item->h as size parameters. There doesn't seem to be any processing of item->rel_w and item->rel_h, which would explain why relative sizes are completely ignored upon creation of the OSD item.

comment:16 Changed 7 years ago by mvglasow (2)

Sorry, my bad, didn't read the entire history. In any case, if the redraw operation caused the crash, this might be fixed by creating a version of osd_std_calculate_sizes which just calculates sizes but does not trigger a redraw.

comment:17 Changed 7 years ago by mvglasow (2)

I think I've found the culprit. Replaying the change from r4819 on top of r5899 and placing tegzed's OSM items into navit.xml I can reproduce the crash.

The issue seems to be that osd_std_calculate_sizes not only updates the dimensions but also attempts to redraw the item, which seems to fail at this stage (and is not necessary anyway, as the item will get drawn later).

After reverting to r5899, I split osd_std_calculate_sizes into two separate functions: one that just (re-)calculates the dimensions, and another that calls the first function and then triggers a redraw.

I inserted a call to the first function just before graphics_overlay_new so that the latter will get called with correct dimensions.

This did require a rename in order to avoid confusing function names – the inner function is now called osd_std_calculate_sizes and does nothing but calculate sizes, and the outer function (which replaces te original one) is now called osd_std_calculate_sizes_and_redraw. They differ in their arguments, as resizing alone does not need the osd_priv structure. This is reflected in calls (which was no big issue as the function is not exported).

I'll test relative placement and, if that works, submit a patch.

Changed 7 years ago by mvglasow (2)

Patch: Handle percentage sizes for OSD elements

comment:18 Changed 7 years ago by mvglasow (2)

  • Keywords patches added

Patch attached, should fix this one and #1098.

comment:19 Changed 7 years ago by mvglasow (2)

A short recap of a conversation with tryagain: There still seem to be some issues when resizing items with relative size/position. Testing found out that these have nothing to do with the patch. We agreed that the patch can be committed, because it improves something and does not break anything. The patch was applied in r5901.

The other issue needs to be looked at separately: When resizing, the content of dynamically sized OSD items turns into garbage (e.g. image if a button OSD) or disappears (e.g. text type OSD). The dimensions themselves are not affected – with the patch they update correctly, without the patch they remain at their default size.

Last edited 7 years ago by mvglasow (2) (previous) (diff)

comment:20 Changed 7 years ago by mvglasow (2)

The resize issue seems to affect only OSD items with relative size. OSD items with fixed size but relative position do not seem to be affected.

Also, only certain OSD types have issues.

I'm still trying to understand what the code is doing. Behavior I observed so far is the following:

  • button will show either nothing or garbage.
  • compass has no issues.
  • navigation_next_turn shows nothing (or garbage) after resize, but will revert to normal when a different instruction is displayed.
  • odometer has no issues.
  • stopwatch has no issues.
  • text will show background but no text at all upon resize (or garbage), but will revert to normal when the text changes.

Garbage seems to be a garbled clipping from nearby screen content (on Linux), occasionally with colors swapped.

I'm trying to find a difference between items that break and those that don't, but no joy so far. If anyone has an idea, any input is welcome.

Last edited 7 years ago by mvglasow (2) (previous) (diff)

comment:21 Changed 7 years ago by mvglasow (2)

  • Resolution set to fixed
  • Status changed from new to closed

I've opened #1260 for the resize bug (as is a different issue from the one originally discussed here), and will close this one.

Note: See TracTickets for help on using tickets.