diff options
author | bptato <nincsnevem662@gmail.com> | 2024-09-19 17:46:27 +0200 |
---|---|---|
committer | bptato <nincsnevem662@gmail.com> | 2024-09-22 22:44:53 +0200 |
commit | 080493c058f52a5c20638f1b975d032af45f4d3f (patch) | |
tree | 60e6ba6b3cb967d29d349018b3f315e7637b4b9e /src/utils/twtstr.nim | |
parent | e23fa780cf2fff7146efcd64b2806ce428858b80 (diff) | |
download | chawan-080493c058f52a5c20638f1b975d032af45f4d3f.tar.gz |
loader: mmap intermediate image files, misc refactoring
* refactor parseHeader * optimize response blob() * add direct "to cache" mode for loader requests which sets stdout to a file, and use it for image processing * move image resizing into a separate process * mmap cache files in between processing steps when possible At last, resize is no longer a part of image decoding. Also, it feels much nicer to keep encoded image data in the same cache as everything else. The mmap operations *should* be more efficient than copying the whole RGBA data through a pipe. In practice, it only makes a difference for loading (well, now just mmapping) the encoded image into the pager, where it singlehandedly speeds up image display by 10x on my test image. For the other steps, the unfortunate fact that "tocache" must delay the next fork/exec in the pipeline until the entire image is processed seems to equal out any wins we might have gotten from skipping a single raw RGBA copy. I have tried moving the delay before the exec (it's possible with yet another pipe), but it didn't help much and made the code much uglier. (Not that tocache didn't, but I can live with this...)
Diffstat (limited to 'src/utils/twtstr.nim')
0 files changed, 0 insertions, 0 deletions