Closed springmeyer closed 4 years ago
Thinking about version to bump to for this change... While the public API has not broken, if any code using generateLayout
was doing anything unique to the output (beyond just passing it to generateImage
) then the mapnik.Image
objects instead of encoded PNG buffers may cause issues.
So, I'm thinking it is safest to bump to 7.0.0
for when this is released.
@jseppi should I update the changelog and bump the version in this PR or should I do it in master after?
should I update the changelog and bump the version in this PR or should I do it in master after?
@springmeyer: Either way is fine with me currently since there aren't any outstanding changes in master
Spritezero has some inefficiencies in the image handling code. This fixes the problems.
Previously:
generateLayout
, only to be then decoded again ingenerateImage
(so the encoding served no purpose). PNG encoding is known to be expensive (since it involves memory allocations and gzip compression).generateLayout
even when the underlying image was never needed. Whenoptions.format
was present, denoting only a data layout, then the only thing needed from the image was the width and height (and not the encoded buffer).Now:
mapnik.Image
instance is passed along togenerateImages
. That function usesmapnik.blend
which supports passingmapnik.Image
objects directly since https://github.com/mapnik/node-mapnik/pull/905.generateLayout
is simplified to avoid needing an async queueThis closes https://github.com/mapbox/spritezero/issues/7
/cc @mapbox/static-apis @mapbox/map-design-api