Jiri Drbalek

On the other hand [`mapnik::save_to_stream()`](https://github.com/mapnik/mapnik/blob/333ef9fde145f88339eaccba810305707bae9b0e/include/mapnik/image_util.hpp#L97-L112) exists in the public interface so it should be simple to expose it in Node.

> I am not sold however, that this would actually lower memory footprint much or at all The goal is not to save memory, rather this: > level of parallelism...

Something like this: ```c++ #include #include template class callback_streambuf : public std::basic_streambuf { public: using base_type = std::streambuf; using char_type = typename base_type::char_type; using int_type = typename base_type::int_type; callback_streambuf(Callback callback)...

I'm sorry for not responding, I have vacation. I will try to take a look on it later this week. > Template parameter std::size_t Size should be an argument provided...

@cklein05 Take a look on https://github.com/mapnik/node-mapnik/pull/799.

> Also, I want to test how different buffer sizes influence the performance. I will make buffer size a parameter of encodeChunked(). It makes sense at least for testing.

Chunk size parameter is there now, see unit tests.

Great elaboration! One could expect upper bound of time saving to be the encoding time. Interestingly, some relative time savings of the random image shows more than 100% of encoding...

> BTW, we've encountered that provided palettes are not handled by the new encodeChunked function. This is fixed and included into the unit tests now. I've also fixed a nasty...

I was doing some simple profiling with perf. From what I could see, time spent by chunking was insignificant next to other calls in Node. I will try to find...