[prosthetiknow]

Description

Fixes #1891, the open report of the bug behind #1160 and #1779. On Linux the editor never shows full detail when zoomed in. The backend renders the full-resolution preview, but WebKitGTK paints the CSS-scaled preview layer at its fit-to-window size and magnifies that bitmap. At 100% the canvas shows a stretched fit-size image, soft or blocky depending on isMaxZoom. The wgpu renderer has been off on Linux since #1061, so every Linux user takes this path.

This keeps zoom sharp on Linux and makes high zoom faster.

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

• Sharp layer - once zoom settles, ImageCanvas portals an <img> of the current preview into a layer that Editor places under the scaled content. The layer is laid out at the zoomed size with no scale(), so the engine paints it at screen resolution. Panning and zooming still move the CSS transform. The stretched SVG image stays until the sharp one loads, so thumbnails and loading look as before. Masks, crop and other overlays draw above it unchanged. It only applies when the wgpu renderer is off.
• Visible-region renders - once the hi-fi target reaches 60% of the original long edge (about 50% zoom), the frontend requests the visible area plus a 15% margin at full resolution, through a new optional regionOnly flag on apply_adjustments. A second preview worker serves these, with its own CachedPreview and GpuImageCache slots. Region and whole-frame renders no longer evict each other's caches or drop each other's queued jobs. Region renders reuse the interactive ROI path at full quality and skip analytics. Whole-frame renders stay at fit size while zoomed, so the histogram still updates.
• Stale preview fix - CachedPreview records the image path. The transform hash covers adjustments only, so a newly loaded photo with identical edits could reuse the previous photo's preview. load_image and clear_image_caches clear the region slots too.
• Region requests build their payload with prepareAdjustmentsPayload, like the other preview requests. decodePatchResponse in useImageProcessing.ts replaces the inline patch-header parsing in executeApplyAdjustments.

Screenshots/Videos

Before:

After:

Testing

• These changes were tested locally by a human and confirmed to work.
• I haven't added any automated tests to the code because the codebase currently lacks a test suite.

Test Configuration:

• OS: Fedora 44, GNOME 50.6 on Wayland, WebKitGTK 2.54.1, 166% display scaling
• Hardware: ThinkPad X1 Carbon Gen 14, Intel Core Ultra X7 358H, Intel Arc B390 (Mesa 26.2.4)
• Files: Fujifilm GFX100 II RAF, 11648×8736, 14-bit and 16-bit lossless compressed

With "Render at native DPI" on, reaching full detail at 100% used to take four whole-frame renders over about 15 s, the last at 11648×8736. A region render now takes 250 to 450 ms, after a one-off cache build per photo.

Not tested on macOS or Windows. Both changes stay off while the wgpu renderer is active.

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

This builds on earlier reports and attempts.

• BUG: Images a little blurry whe zoomed in #1160 was the first report, on the Flatpak. It closed after Linux Compatibility Mode made zoom sharp for the reporter. That mode turns off WebKit compositing, and for many users it leaves the window invisible or flashing until something moves (BUG: Image Quality Worsens when disabeling the sourcs panel from the editing Window. #1779, BUG: Images not rendering in full detail at 100% zoom 1.6.5 #1891, BUG: Rapid Raw versions 1.6.3 and 1.6.4 only show an icon in the toolbar at the bottom of the screen. Otherwise, the screen remains blank. #1744). This PR needs no compatibility mode and no environment variables.
• fix: canvas renderer layer for live preview #1198 by @rhysgs traced the blur to the zoomed image landing on its own compositing layer once a side panel scrolls, and drew the visible crop into a canvas instead. It stalled on panning speed and on thumbnails during loads. This keeps CSS transforms while moving, and only swaps in the sharp layer when still.
• BUG: Image Quality Worsens when disabeling the sourcs panel from the editing Window. #1779 closed as a duplicate of BUG: Images a little blurry whe zoomed in #1160. @lalibertemarc narrowed it to WebKitGTK compositing, which depends on the open right panel, and asked for someone who could reproduce it to take it on. I can reproduce it reliably on a 166%-scaled display.
• BUG: Direct wgpu renderer glitches #1060 and fix(linux): gpu - skip surface creation on Linux #1061 turned the wgpu renderer off on Linux. That path is how macOS and Windows avoid WebKit for the canvas.

Related

• feat(viewer): show the edited image in a second window, with zoom and pan #1949 adds separate preview and GPU cache slots for its viewer. If it lands first, the region slots here should move onto its clear_preview_slot helper. Its Linux viewer places JPEGs with a CSS transform, so the sharp layer would help there too.

AI Disclaimer:

Please state the involvement of AI in this PR:

• This PR is created by an AI agent
• This PR is mostly AI-generated but edited/merged together 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)