fix: canvas renderer layer for live preview

[rhysgs]

Description

Solves issue relating to the live preview in some situations being put onto a different compositing/rendering layer resulting in significantly worse image quality in the live preview.

This specifically occurred when the image was zoomed in and then panned in such a way that the heavily scaled image had hidden overflow that would be put behind another div that was scrollable (in the case I found it was the editor side bar).

See here for my original evidence of the issue
#1160 (comment)

Admittedly I don't have a system I can use that would correctly allow the GPU and enable isWgpuActive for me to confirm this is doesn't break that.

At the very least please treat this as a POC that the blurry issue is real and can be solved.

Type of Change

• Bug fix
• New feature
• Breaking change
• Performance improvement
• Code refactoring
• Documentation update
• UI/UX improvement
• Build/CI or Dependency update

Changes Made

Image is no longer plainly placed as a pannable image being scaled and moved. The view port previously being calculated is now instead used to render a crop of the original image into a canvas that occupies the live preview viewport. This simplifies the view layers greatly for the system having to render this. The canvas is never behind other elements (compared to the image which was scaled and translated way out of bounds behind other things with hidden overflow).

Performance should be comperable I couldn't spot a difference by eye. I've only tested on my linux machine though.

Being in a canvas we now have full control of how the cropped viewport of the live preview is rendered.

Screenshots/Videos

Before

Screencast.from.2026-05-22.22-04-29.webm

After

Screencast.from.2026-05-22.22-02-18.webm

Testing

• I have tested these changes locally and confirmed that they work as expected without issues

Test Configuration:

• OS: Ubuntu 24.04
• Hardware: AMD 7600, AMD 7800XT, QHD Monitor

Checklist

• My code follows the project's code style
• I haven't added unnecessary AI-generated code comments
• My changes generate no new warnings or errors

Additional Notes

AI did a lot of the math for the translations to put the image into the canvas view. I'm sure this all could be refined further.

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is entirely AI-generated
• This PR is AI-generated but guided by a human
• This PR was handwritten with AI assistance (spell check, logic suggestions, error resolving)
• This PR contains only blood, sweat, and coffee (AI-free)

[CyberTimon]

Hi @rhysgs

Thanks for the PR!

I noticed that the thumbnails no longer display at all while the actual image is loading. This happens universally, not just when the WGPU renderer is active. Could you please look into why this is happening and fix it?

Also, are you 100% sure the performance isn't worse with this approach? I actually tried to implement a canvas-based preview here once before, but found that the performance (especially during rapid mouse movement) was much worse compared to just updating the CSS transforms on the SVG. Lastly, I think you should add an active/cleanup flag to your new Image() onload handlers, otherwise it can cause flickers while dragging sliders rapidly. :)

Thanks!

[rhysgs]

@CyberTimon Thanks for checking out the PR, it is an interesting project! Some of the files are quite unwieldly (2,000 line react components) but it's quite exciting to see something that focuses on the basics (DarkTable is too in the weeds for me, feels more like a science experiment than a post production editor)

As for the performance concerns, this has a 100% chance of performing worse with this approach. There is no way it isn't with the extra layer of JS transforming and re-assigning the canvas content. It's not clear how to quantify that to measure the real impact but I found the experience on this branch perfectly acceptable. Though someone with less modern hardware would be a better fit for commenting on it. Modern hardware can brute force many things.

Unless the problem can be solved without a canvas respectfully it doesn't matter how fast the transformed svg strategy runs. If it doesn't fulfill the basic functional requirements of displaying an image without degredation it's not a solution. Software about editing images must render the live preview as faithfully as possible before anything else, optimisation before that is premature novelty.

It would be nice to keep the svg solution as it is simpler to reason about, but it appears to be a fundamental limitation of how layers are rendered when the composition layers includes a scrolling container. Tauri is nice that you don't need to bundle chromium, but that also means you don't control the version it runs on..

Thank you again for checking out the PR! I'll check out the onload hooks and flickering issue you've described that's no good, hard to spot regressions as someone very new to this project :)