Move map printing to a node process

[okdistribute]

Right now, the map printer is in it's own electron renderer -- see desktop architecture diagram. Ideally, this would be in a node process instead, for performance reasons. But to do that, we need mapbox-gl-native to work with Node 12.

Unfortunately, mapbox-gl-native does not work with Node 12, and Mapbox has said they have discontinued support for the Node bindings. See the following discussion to follow along:

• Request: Node v12 binaries? mapbox/mapbox-gl-native#16418
• @mapbox/mapbox-gl-native not available (403 status code) on npm mapbox/mapbox-gl-native#16485

[brianreavis]

mapbox/mapbox-gl-native#16485 (comment)

[gmaclennan]

I'm not sure that performance is a reason for doing this. mapbox-gl-js (which we currently use) can render 60fps in most browsers. For rendering a static map the render time should be insignificant. In initial testing I saw that most of the time taken for rendering a static map is downloading resources (vector tiles, sprites, font sdfs). It is possible that the web version could be faster here too, since the browser does caching of resources and mapbox-gl-js has been heavily optimized for performance (using worker threads etc). In addition, in the past the native-gl version has lagged behind the JS and Android/iOS versions in terms of features and rendering bugs, which results in differences in how the map appears.

I think if we are going to switch from the current architecture (rendering in an electron renderer, essentially rendering in Chrome) then we should measure the performance first to check if it is a reason to try to change things. We should also bear in mind the potential risk of rendering diverging from what the user sees in the other map views in the app, which use mapbox-gl-js on Desktop, and the Android SDK on mobile.

[okdistribute]

@gmaclennan I meant performance in terms of the amount of time it takes to render a full PDF (>50 pages for example takes a few minutes right now) rather than FPS. I'd hope that would be faster with the native implementation, although I haven't been able to try it (and yes I agree that testing the difference would be a good idea).

[okdistribute]

Thank you @brianreavis !

[gmaclennan]

@gmaclennan I meant performance in terms of the amount of time it takes to render a full PDF (>50 pages for example takes a few minutes right now) rather than FPS. I'd hope that would be faster with the native implementation, although I haven't been able to try it (and yes I agree that testing the difference would be a good idea).

Yes, I believe most of that time is downloading resources, not the actual rendering. That's what I saw when testing doing parallel renders to speed things up (it didn't). It would be good to actually measure and check that though.