crash when trying to open large images

[Byron]

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:

2023-05-01T05:19:02.512601Z  INFO bevy_render::renderer: AdapterInfo { name: "Apple M1 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
2023-05-01T05:19:02.694028Z  INFO bevy_winit::system: Creating new window "Image Maniac" (0v0)
2023-05-01T05:19:02.816696Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 13.3.1 ", kernel: "22.4.0", cpu: "Apple M1 Pro", core_count: "10", memory: "16.0 GiB" }
2023-05-01T05:20:00.384561Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (0)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
    Dimension X value 17160 exceeds the limit of 16384

', /Users/byron/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.15.1/src/backend/direct.rs:3024:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'Compute Task Pool (0)' panicked at 'A system has panicked so the executor cannot continue.: RecvError', /Users/byron/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.10.1/src/schedule/executor/multi_threaded.rs:194:60
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /Users/byron/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_tasks-0.10.1/src/task_pool.rs:376:49
thread 'Compute Task Pool (0)' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', /Users/byron/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.10.1/src/pipelined_rendering.rs:136:45
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/byron/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_tasks-0.10.1/src/task_pool.rs:376:49

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)

[AllenDang]

Thanks to do the test, let me see what i can do

[AllenDang]

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

[Byron]

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 :).

[AllenDang]

@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.

[woelper]

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!

[Byron]

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.

[woelper]

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.

[Byron]

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.

[woelper]

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?

[Byron]

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.

Screen.Recording.2023-07-04.at.10.22.18.mov

[woelper]

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?

[Byron]

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.

Screen.Recording.2023-07-04.at.10.36.58.mov

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 😅.