Open Byron opened 1 year ago
Thanks to do the test, let me see what i can do
I limited the maximum image size to 16384x16384 for now, in the mean time I'll still try to find out a way to load huge image
Awesome, thanks!
[..] in the mean time I'll still try to find out a way to load huge image
If you would manage to pull that off, you'd definitely be one of the first if not the first! Sure, there are always limits, but they can definitely be stretched :D. For codevis the key was to use memory maps, which allowed to handle projects that want to be 80 thousand pixels across, like webkit
.
It's interesting to see how no app I tried was able to decently handle these pictures, not even the ones I'd expect to be very well tested like Preview
on MacOS, but to add insult to injury they won't even degrade gracefully.
Anyway, I wish you the best of success, and codevis
applied to the linux kernel or webkit (dwarfing the linux kernel) will provide the kind of images I am talking about :).
@Byron Thanks for the hints. ChatGPT suggests almost the same, memmap, multi-thread reading, multi-thread generating thumbnails, it's very interesting and challenging, :P BTW, macOS's preview works like a magic, I'm very curious about how they did so well.
I am working on a similar image viewer, and I've cheated by resizing larger images into a texture of supported max dimensions and showing a warning. That way users can at least see the image - maybe that could be a temporary workaround? Great work by the way!
Thanks for sharing, @woelper, and thanks for sharing oculante
! The proposed workaround seems like a viable way to handle this.
Somehow I thought that oculante
already implements this and tried to open the image above - then I saw the warning and expected it to resize the image, and as the spinner kept spinning I thought it was doing something. It took me a while to find out that it's not actually doing something, despite the 20% or so of CPU it seems to consume when idle, but the lack of IO and allocations finally tipped me off. I think it's a general issue that when something can't be opened, the "Loading" message with spinner stay present, and it can more easily be reproduced by opening a non-image file.
Thanks! Yes, this should be supported. Did you use the large image linked above? I will test with that one and see what went wrong in this case. Thanks for the other discoveries, I'll add issues for them.
Yes, this should be the image I used: https://github.com/Byron/gitoxide/releases/download/v0.16.0/git-100k-scloc.png .
And thanks for the fixes, too! oculante
looks very capable and I would love to use it more. My major gripe is that it seems to stutter even if nothing is happening, and I can't move the window without it getting stuck for a second or two. Might be my setup, it's an M1 and I ran it from the at that point in time latest main
.
Thanks for linking the image! I use it on mac as well (M2), but have not seen any stuttering, although the cpu usage seems higher on mac than on linux. Could you try a release build (app bundle) from the releases tab, such as this one?
Thanks for looking into this :)!
I tried the linked app and it's the same. To better illustrate what I mean, please find attached a video.
https://github.com/AllenDang/img_maniac/assets/63622/6c2e30d6-ba8c-4719-a323-eea1b5412f8b
Thanks. wow, that's really odd. I sadly could not reproduce this neither on an Intel nor m2 Mac. I wonder what is causing this, maybe winit
related?
I think I figured it out! It's the Magnet app that's causing the stuttering, and it's broken so badly that I can't even let it "ignore" the app as the popup closes immediately after hanging.
https://github.com/AllenDang/img_maniac/assets/63622/eda147b1-51c7-4325-b40d-d5225da878a1
Indeed, it might be something related to window handling, maybe winit
is unusually slow in responding to events. Maybe, just maybe, the cause of this is related to the application being constantly busy. Maybe that busyness clogs the eventloop somehow?
By the way, I wouldn't mind moving this conversation elsewhere as it is quite off-topic now 😅.
Thanks for making this tool! While checking if this could be an image viewer that can handle ridiculous image sizes, I encountered a crash.
Observation
When opening an image with dimensions larger than 16384 pixels, it crashes with:
Expectation
It knows its limits and communicates the issue without crashing.
Reproduction
This is the image I tried to open the full-size version of (https://github.com/Byron/gitoxide/releases/download/v0.16.0/git-100k-scloc.png)