Mepo - August update: 1.2.0 Release / Improved pin rendering performance

Message ID
DKIM signature
Download raw message
Hi all - welcome to the August update for Mepo, the fast, simple, and
hackable OSM map viewer for desktop & mobile Linux devices. This update
covers the release of Mepo 1.2.0 which largely focused on improvements to
the application's performance when rendering large numbers of pins. You
can follow Mepo's development at http://sr.ht/~mil/mepo and do note
that release notes are also mirrored in the git annotated tags for
each release.

- Mepo 1.2.0 Release Notes
- Packaging Updates: Alpine package & Flatpak updated to 1.2.0
- General Project News


# Mepo 1.2.0 Release Notes
This release addresses several long-standing but important performance
improvements and bugfixes. Most notably this release drastically
improves performance of rendering with large number of pins onscreen
(addressing ticket #26) by implementing a caching layer for pin
rendering. Additionally, this release updates the codebase to build
against Zig 0.11.x. Major changes listed below:

1. Implementation of a caching layer for pin rendering
Pin rendering since initial implementation has been based on a naive
rendering per-frame strategy. As a result, in 1.1 and earlier versions,
dragging the screen forces (an often) slowed / lagged performance
depending on the number of pins onscreen. This was most noticeable with
a large number of pins on the screen in an activated unordered group
(due to slow font rendering for each pin's label) and ordered groups
(due to the underlying antialiased connecting line drawing function
being a relatively expensive operation).

To address this performance hit, in this release an intermediate caching
layer has been implemented for pin rendering. The implementation is
similar to how PNG caching operates for OSM tiles. For pins, however,
*transparent* tiles are computed with the graphical rendered pin data
(e.g. pin, connecting paths, font text, etc.); and this data is cached
as a SDL texture just as PNG OSM tiles are similarly cached on an XYZ
basis. Accordingly, when dragging the viewport, pin layer (re)rendering
only applies if there is a change (e.g. a new pin, etc.) or the pin tile
is absent from the cache. In most cases, the cache is utilized to pull
the computed pin 'overlay tile'. The net effect end-users will notice
is that dragging is smoother when a large number of pins are present
on screen. The most noticeable on mobile devices where performance
was previously bottlenecked in the old/removed per-frame pin rendering
strategy / implementation.

This closes (#26).

2. Switch to select SDL auto renderer by default & -hw & -tw CLI flags
Rather then by default attempting to force the SDL hardware renderer,
now 0 is used for the SDL_CreateRenderer default flags. This select the
hardware renderer when available and falls back to software renderering
when hardware rendering is not available. This fixes the inconvenient
functionality where you would need to manually pass the -sw flag when
the hardware rendering would fail to initialize on certain platforms.

In addition to switching to use the SDL auto renderer, two new CLI flags
have been added related to SDL renderering:

-hw: The new -hw flag mirrors the -sw flag in that the -hw flag forces
the hardware renderer rather then the default auto renderer functionality.

-tx: And, the new -tx flag allows you to specify the number of textures
to be loaded into memory for the OSM tile and new pin overlay tile
caches. By default this is set to 200 textures. Specify -tx# to change
this as desired.  For example, to reduce the number of textures cached
to be 100, you could run `mepo -tx100`.

3. Update to Zig 0.11.x and Unpinning Zig patch number
The codebase has been updated to build against Zig 0.11.x thanks to
Nguyễn Gia Phong (cnx). Additionally, it was pointed out by laalsaas
that Zig patch numbers won't break builds so from now on, our builds
don't depend on a specific zig patch number (e.g. 0.11.0); but rather
only on the major/minor revision (e.g. 0.11.x).

4. Misc updates: PNG errorcheck, Init STDERR debug, contributor fixes
Lastly, a few minor additional bugfixes & updates have been addressed in
this release I'll mention here. Firstly, in previous releases invalid
PNG data loaded from tileservers could be downloaded and inadvertently
saved to the filesystem. This has been resolved and now only valid PNG
data (checked before write) will be saved to the filesystem. Secondly,
debug STDERR messages in the early application initialization stage are
now shown by default which should enable easier debugging in early boot
stages of the application. And finally contributors sent a few fixes
which have been merged; git shortlog from contributors below:

Nguyễn Gia Phong (5):
      Specify build for Zig 0.11
      Refactor redundant pin cycling logic
      Replace deprecated std cstr.cmp with mem.orderZ
      Use Zig 0.11 syntax for captured index in for loop
      Port to Zig 0.11 builtins with type inference

laalsaas (1):
      unpin zig patch number

lpt (1):
      mepo_ui_menu_user_pin_updater.sh: fix == in place of =

Jan Beich (1):
      Use OS-independent sigaction after fc6156a833bb


# Packaging Updates
Between yesterday and today I've updated the Alpine package and the
Flatpak on Flathub to 1.2.0. If you are a package maintainer for Mepo
on another distribution please get in touch if you have any difficulties
with the 1.2.0 update.


# General Project News
Mepo is overall in a stable spot and in more of a maintenance and
improvement then development / adding features mode. Top priority for
development next up is largely #59 which is an outstanding bug related
to the SDL text input API and #65 to make shellpipe_sync non-blocking /
cancellable in the UI.

If you missed it, I am also working on a new project Mobroute which is a
FOSS public transportation router (based on GTFS) which will eventually
have good OOTB integration with Mepo. You can see more details on the
Mobroute project at: http://sr.ht/~mil/mobroute . 

If you have any ideas for features or improvements on Mepo, want to get
involved in development, or notice any bugs, please get in touch on the
mailing list, the ticket tracker, or IRC.

Reply to thread Export thread (mbox)