fpw / avitab

X-Plane plugin that displays a tablet to aid VR usage
GNU Affero General Public License v3.0
300 stars 59 forks source link

Optimisation and enhancements to map overlay drawing #188

Closed mjh65 closed 9 months ago

mjh65 commented 10 months ago

This change includes some refactoring and optimisation to the map overlays, partly inspired by separate development of a SQL-backed NAV database, which required API changes to the visit() interface, and resulted in this more extensive update.

The selection of nodes for display in the overlay has been partly delegated to the world's visit() function. (This capability was added to a previous refactoring PR, and is now being used.) This reduces the number of nodes that need to be processed in the OverlayMap class.

Each NAV node that is going to be displayed as a map overlay has a paired overlay node object created. These are now cached and reused in the next frame (if still selected for display) which reduces the overhead of overlay nodes that are destroyed and recreated on each frame.

Decisions on what to draw, and in what detail, are based on the density of NAV node information on the map, rather than the map width. The information density is estimated using the densenst lat/lon area within the visible map area. This particular update is also related to the future SQL-backed NAV database, where the reporting of NAV nodes over large areas will need to be completed over several (possibly many) display frames due to the time required to search the SQL database. But more on that later.

A change in mouse click behaviour has been added to support clicking near overlayed node information to show more detailed text about the node. Previously using the mouse to pan would also highlight the node nearest the pan start location. The update now means that only a stationary (or small movement) mouse click is treated as a request to highlight the nearest node.

The branch used for this PR is based on a previous PR, and therefore currently also includes 3 duplicated commits. I'm assuming the other PR will be separately approved first, and then this PR can be merged afterwards.