Opened 10 years ago

Last modified 4 years ago

#1139 new defect/bug

Corrupted map rendering on panning

Reported by: usul Owned by:
Priority: major Milestone: version 0.6.0
Component: core Version: git master
Severity: complex Keywords: generalisation, buildings, map, pan
Cc: sebastian.leske@…

Description (last modified by usul)

Hi, this continues #1050 and is about the broken generalization and rendering, when you move the map. This results on artifacts due to the current generalization strategy that might be a bad choice esp. for buildings:

In #1050 user:sleske explains out about further technical details.

I have no idea what might be the best fix, but I like to suggest a few ideas:

  • disable generalisation - we need to check how this influences the performance on embedded devices
  • disable generalization for buildings - introduce the ability to set the strategy on different item classes. Maybe this can be combined to use some kind of layers to speedup this process and avoid the check per object

broken buildings, now only when you move the map

Attachments (1)

Rostock_moving.png (123.4 KB) - added by usul 10 years ago.
broken buildings, now only when you move the map

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by usul

broken buildings, now only when you move the map

comment:1 Changed 10 years ago by usul

  • Milestone set to version 0.5.1

comment:2 Changed 9 years ago by usul

  • Description modified (diff)

comment:3 Changed 9 years ago by sleske

Also see this forum thread: Why the special case in point reduction in transform.c?.

There, Mapmapper points out that we should probably not pan the map by constantly redrawing it:

Other maps move only the picture of the map und there is an empty grey area on the former place after dragging, that is filled after a while. The rebuild of the map is unvisible in backround [...]

This is probably what we should do to get panning that performs well and looks identical to the static map display. Of course, we'd need to check whether all graphics backends support moving the rendered map image around.

comment:4 Changed 9 years ago by sleske

  • Cc sebastian.leske@… added

comment:5 Changed 9 years ago by tryagain

Actually, navit will attempt to pan the map by positioning rendered bitmap if drag_bitmap attribute of <navit> tag is set to true.

(1) But then we have ugly black surrounding the rendered area of the map until the map is rendered at the new position. I think that color should be lay-out defined (black will probably be good for the night layout, while others definitely require something more light). Update: the <layout> tag has the color attribute which looks pretty suitable for our needs.

(2) Also, there will be a problem with image and button osd types: they will be dragged together with the map, while textual osds will disappear for that time. When panning will be done, all osds will reappear at the right position.

To make those image osds disappear as others do, one should switch on the use_overlay attribute of each affected <osd>. But then:

  • with gtk_dravig_area graphics we get the "blue circumference" bug described on #860.
  • on android device, all images with use_overlay enabled do not get drawn at all.

IMHO (2) is a question for a separate ticket.

Last edited 9 years ago by tryagain (previous) (diff)

comment:6 Changed 9 years ago by sleske

Interesting, thanks for the information.

I think it is perfectly acceptable to hide all OSD element during panning. So we should try to accomplish that. The border should automatically be drawn in a suitable color (maybe the background color of the layout, as you suggest). For bonus points, we could trigger a redraw if enough of the image has been panned off-screen. Ideally, we'd draw a bit more than the visible area internally, so you can pan a bit without getting a blank area. We'll have to see what's practical...

The "overlay" feature will probably help with that. However, it appears to be a bit buggy. See e.g. #983 for another problem (incorrect image rendering).

comment:7 Changed 9 years ago by tryagain

I have investigated the subject a bit more.

sdl graphics plugin does not have support for bitmap_drag.

SDL itself seems to have double buffer which is used to have smooth redrawing. We'll probably have to create another (third) buffer to store the bitmap being dragged, which may affect memory appetite and performance. Should it be configurable?

comment:8 Changed 9 years ago by usul

  • Severity set to complex

comment:9 Changed 5 years ago by

  • Milestone changed from version 0.5.1 to version 0.5.2

This ticket was pushed back in order to bring 0.5.1 out soon.

comment:10 Changed 4 years ago by

  • Milestone changed from version 0.5.2 to version 0.6.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.