Can the render API generate outputs to memory directly?

[YinlinHu]

The temporary PPM file which will involve disk operations may be a bottleneck for heavy rendering operations. Some memory image types may be preferable.

https://github.com/innodatalabs/redstork-ui/blob/2f5f23ac4c0f017cca35b69f686aab1eb6528ef3/ui/presenter/page_presenter.py#L27

[mkroutikov]

You are right. Here I strive for simplicity, not performance. To make it file-less, one have to

1. alter C++ rendering function to write to a buffer
2. pass this buffer from the rendering thread to the main UI thread
3. render it using QImage.fromBuffer()

This is relatively straightforward, but I am not sure it gives any real advantage. Do you have a use case that requires fast rendering? Just flipping through the pages with PgDown seem already responsive.

[YinlinHu]

Thanks for your clarification. If you can try my self-used pdf manager at https://github.com/YinlinHu/kuafu, you will notice how rendering speed is highly appreciated when you drag the scrollbar. PS: you need to apply the PR first: https://github.com/innodatalabs/redstork/pull/4

[YinlinHu]

After some hacking, it works in my projects. Thanks very much.

[mkroutikov]

I wonder if you can share the numbers: how much faster rendering to buffer is, comparing to rendering to a file?

[YinlinHu]

I wonder if you can share the numbers: how much faster rendering to buffer is, comparing to rendering to a file?

On my machine (high-performance SSD), the PPM file saving is extremely fast, so the overall rendering time of the file-version is comparable to the memory-version (only about 2-3% speed drop). But the disk operations are unnecessary in my case. At the meantime, the PPM files are big and may have negative effects on the lifetime of my SSD :-) ...

[mkroutikov]

Thank you for clarification (and contributing rendering-to-buffer code)!