codevis
codevis copied to clipboard
sloganking
Output resolution
User should be able to define a desired resolution that the render function will output an image as. This may require upscaling or down scaling the output image.
Questions
- Outputted aspect ratio is not perfect. What should we do about the differences?
@Byron Do you have any idea how we can convert ImageBuffer<Rgb<u8>, MmapMut> outputted by render() into a DynamicImage so that we can call resize() on it? I seem to be having trouble.
DynamicImage implements From<ImageBuffer<Rgb<u8>, Vec<u8, Global>>>, but not From<ImageBuffer<Rgb<u8>, MmapMut>>. I don't have the best understanding of MmapMut yet, but it's my understanding we started using it so we can generate larger images by writing to swap memory if we run out of RAM.
https://docs.rs/image/latest/image/enum.DynamicImage.html#method.into_bytes
The above DynamicImage doc comment makes me think DynamicImages can contain ImageBuffers with something other than a Vec<u8> as their container, but I am not sure.
I suppose worse come to worse I can replace all usages of ImageBuffer with DynamicImage, but I think that'd come at a runtime performance cost.
Actually Rust Enums can only contain types, not traits. So It doesn't look like it's possible for a DynamicImage to contain ImageBuffer<Rgb<u8>, MmapMut>, since DynamicImage are enums. My silly mistake.
Sorry for the late reply!
Indeed, DynamicImage can't be used here as it hard-codes certain combinations of types enforcing a certain storage backend, Vec<u8> in this case. My recommendation is to see how the resizing is implemented and copy the required bits and pieces. These lower level components will be parameterized to support generic images I am sure and you should be able to use them with other storage backends, like MmapMut.
If this is troublesome, please let me know and I will take a stab at it - replacing MmapMut with Vec<u8> just for that would be too much of a loss for me.
Maybe I can copy all the methods in DynamicImage and expose a DynamicMmapImage type. I'll look into it.
The only previous Mmap discussion I can find: https://github.com/sloganking/codevis/pull/11#issuecomment-1237329666
MmapMut's documentation seems a little unintuative for someone who's not already informed. @Byron can you remind me of it's exact function? I don't seem to be able to render the Linux kernel with it on a machine that has 16GB of memory. Which is unexpected if it's using disk to expand it's memory capacity like I think it does. Also we were originally playing of the idea of using it to enable multi-threading, but it's my understanding that we enabled that via a different method.
I don't seem to be able to render the Linux kernel with it on a machine that has 16GB of memory.
I'd be interested in learning more. What does that mean exactly? Maybe it matters which OS you are on as well. I recommend running with the flags that increase verbosity, then you can see where it struggles - sometimes it's the syntax highlighter that takes a long time.
Also we were originally playing of the idea of using it to enable multi-threading, but it's my understanding that we enabled that via a different method. can you remind me of it's exact function?
Indeed, its only function is to support handling images that don't fit into memory all at once.
As an anonymous mmap is supposed to be transparently backed by a file on disk, and I'd think that's independent on the system's swap size as well. It's benefit is that it will be removed automatically when the process terminates if it ever existed.
If it doesn't seem to have the effect it should have, maybe it's possible to experiment with explicitly backing it by a known file - then we'd be responsible for removing it when done, but at least you can validate that it's not memory that is the issue when rendering the linux kernel, but something else maybe.