SWT drawImage Performance Regression On Windows

[Bio7]

SWT Windows drawImage Performance Regression

Describe the bug

SWT's Canvas.drawImage() is 5–20x slower on Windows displays since around SWT 2025-12. Image zoom operations that took 5–8 ms now take 35–150 ms, causing visible UI stalling.

To Reproduce

import org.eclipse.swt.SWT;
import org.eclipse.swt.events.PaintEvent;
import org.eclipse.swt.events.PaintListener;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.Rectangle;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.*;
import java.io.InputStream;
import java.net.URL;

public class SWTZoomPerformanceBugExample {
    private static Image image;
    private static double zoomFactor = 1.0;

    public static void main(String[] args) {
        Display display = new Display();
        Shell shell = new Shell(display);
        shell.setText("SWT Zoom Performance Test");
        shell.setSize(800, 600);
        shell.setLayout(new GridLayout(1, false));

        try {
            URL url = new URL("https://imagej.net/ij/images/NileBend.jpg");
            try (InputStream in = url.openStream()) {
                image = new Image(display, in);
            }
        } catch (Exception e) {
            image = new Image(display, 500, 500);
            GC gc = new GC(image);
            gc.fillRectangle(0, 0, 500, 500);
            gc.dispose();
        }

        Composite controls = new Composite(shell, SWT.NONE);
        controls.setLayout(new GridLayout(2, false));
        controls.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false));

        Label label = new Label(controls, SWT.NONE);
        label.setText("Zoom: 100%");

        Scale scale = new Scale(controls, SWT.HORIZONTAL);
        scale.setMinimum(10);
        scale.setMaximum(500);
        scale.setSelection(100);
        scale.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false));

        Canvas canvas = new Canvas(shell, SWT.DOUBLE_BUFFERED | SWT.NO_BACKGROUND);
        canvas.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true));

        scale.addListener(SWT.Selection, e -> {
            int selection = scale.getSelection();
            zoomFactor = selection / 100.0;
            label.setText("Zoom: " + selection + "%");
            canvas.redraw();
        });

        canvas.addPaintListener(new PaintListener() {
            @Override
            public void paintControl(PaintEvent e) {
                GC gc = e.gc;
                Rectangle clientArea = canvas.getClientArea();
                gc.setBackground(display.getSystemColor(SWT.COLOR_WHITE));
                gc.fillRectangle(clientArea);

                if (image != null && !image.isDisposed()) {
                    Rectangle srcBounds = image.getBounds();
                    int destWidth = (int) (srcBounds.width * zoomFactor);
                    int destHeight = (int) (srcBounds.height * zoomFactor);

                    gc.setAntialias(SWT.ON);
                    gc.setInterpolation(SWT.HIGH);

                    long drawStart = System.currentTimeMillis();
                    gc.drawImage(image, 0, 0, srcBounds.width, srcBounds.height, 
                                 0, 0, destWidth, destHeight);
                    long drawEnd = System.currentTimeMillis();
                    
                    System.out.println("drawImage duration: " + (drawEnd - drawStart) + " ms");
                }
            }
        });

        shell.open();
        while (!shell.isDisposed()) {
            if (!display.readAndDispatch()) {
                display.sleep();
            }
        }

        if (image != null && !image.isDisposed()) image.dispose();
        display.dispose();
    }
}

Steps:

1. Run on Windows
2. Adjust zoom slider
3. Observe console output: drawImage duration should be ~5–8 ms but is 35–150 ms

Expected behavior

• GC.drawImage() completes in ≤10 ms (matching SWT 2025-09)
• Faster zoom slider interaction

Actual behavior

• GC.drawImage() takes 35–150 ms
• Visible UI stalling during zoom operations

Environment:

1. Platform:

   • Windows
   • Linux
   • macOS

2. Additional OS info:

   • Windows 10 Build 22H2 / Windows 11 Build 22H2

3. JRE/JDK version:

   • Adoptium JDK 25

Version since

SWT 2025-12 (initial regression)

• SWT 2025-06: ✅ ~5–8 ms (tested, working)
• SWT 2025-09: ✅ ~5–8 ms (working according to KI analyses)
• SWT 2025-12+: ❌ ~35–150 ms (broken)
• SWT 2026-06: ⚠️ Slightly improved but still slow

Workarounds

1. Revert to SWT 2025-09 (full fix)

[HeikoKlare]

Can you share the monitor zoom at which you experience the slowdown? Are you at 100%?

With the 2025-12 release, the implementation for drawing scaled images was significantly revised. In particular, a new, simplified method for just drawing a scaled (non-cropped) image has been introduced: https://eclipse.dev/eclipse/markdown/?f=news/4.38/platform_isv.md
Can you check if using that method improves performance for you? If yes, maybe that would be a reasonable alternative anyway.

[Bio7]

I was at 100% (at home I'm using MacOSX without these problems).
I used the method of the example above but can't prove the new method now.
Why would that make a difference? Have you tried the snippet?

[HeikoKlare]

I have tried the snippet now, but first wanted to make sure that I test the right thing before investing time.

I can only partly confirm the reported behavior. For me, the performance degrades by factor 2, not by factor 7 or more like reported.
If I understand correctly, with the revised implementation in 2025-12, the image is now provisioned in a properly-sized handle (which does not require the GC to do additional scaling) whereas it was was provisioned at 100% scale before which then required the GC to do the scaling. The benefit of the previous approach was that the first draw operation of an image at a new scale was faster. With the new approach, while the first draw operation for a new scale is slower, every subsequent one is significantly faster. You can see that in the printed durations when, e.g., moving the shell out of the monitor and moving it back in, or when just resizing the shell.
Since the latter is the more relevant (as the more often occurring) use case, optimizing that one obviously makes more sense (in addition to sharper results with the new approach in case you have an image that can be provisioned in different resolutions).

In case you see a chance for improving the implementation, you may of course propose an according change.

[Bio7]

Thanks for the fast analysis. However I really saw a difference in performance when scaling images up and down. I tested this with an old Eclipse instance (2025.06) where the zooming was really faster.

Claude gave me this analysis and bug report according to the GIT changes (the following is the AI Output). But some of the workarounds are not really an improvement:

================================================================================
BUG REPORT: SWT Windows drawImage Performance Regression on HiDPI Displays

SUMMARY

SWT's Canvas.drawImage() performance has significantly degraded for medium to
large RGB images on Windows HiDPI displays (>100% DPI scaling) between versions
2025-09 and 2026-06, resulting in unacceptable redraw latency for zoom operations.

AFFECTED VERSIONS & PLATFORM

• Affected: SWT 2025-12 (initial regression) → 2026-03 → 2026-06 (partially improved)
• Working: SWT 2025-09 and earlier
• Platform: Windows (7, 10, 11)
• Trigger Condition: HiDPI displays (≥150% DPI scaling), RGB images ≥2000×2000 pixels

ISSUE DESCRIPTION

When drawing a scaled image via gc.drawImage() on a Windows system with HiDPI
scaling enabled, the operation now takes significantly longer than in prior versions:

Example Performance Impact:

• Image size: ~4200×4200 pixels (RGB)
• Display: 150% DPI scaling
• Operation: gc.drawImage(image, srcX, srcY, srcW, srcH, dstX, dstY, dstW, dstH)
• SWT 2025-09: ~5–8 ms per call
• SWT 2025-12–2026-06: ~35–150 ms per call (5–20x slower)

This causes visible stalling and poor user experience during:

• Image zoom in/out operations (slider-driven redraws)
• Panning or interactive image manipulation
• Any Canvas repaint loop that includes drawImage() calls

ROOT CAUSE ANALYSIS

Between 2025-09 and 2025-12, SWT introduced a new multi-zoom HiDPI coordinate
transformation system. The following changes triggered the regression:

1. Zoom-Aware Handle Lookup (2025-12)

   • Every gc.drawImage() call now invokes image.getHandle(gcZoom, nativeZoom)
   • On HiDPI displays, this triggers lazy image re-scaling to match native DPI
   • Example: A 4200×4200 image is internally scaled to 6300×6300 (at 150% DPI)
   • This re-scaling happens on every repaint, not cached per zoom level

2. Operation Recording Wrapper (2025-12–2026-03)

   • GC drawImage calls wrapped in operation-recording machinery
   • Recording overhead reduced in 2026-06 commit c6bf2e9, but handle lookup remains
   • Commit ad31f60 removed SetProcessDPIAware override, potentially affecting
     DPI coordinate handling on some JVM configurations

3. Missing Caching/Optimization

   • No caching of re-scaled image handles per zoom level
   • No fast-path for identity or common zoom levels
   • Handle lookup happens synchronously on every draw call

REPRODUCTION CASE

Use the provided Java code: SWTZoomPerformanceBugExample

Steps:

1. Compile and run on Windows with ≥150% DPI scaling enabled
2. Load a large image (≥2000×2000 pixels) via the URL:
   https://imagej.net/ij/images/NileBend.jpg
3. Adjust the Zoom slider to trigger canvas redraws
4. Observe the logged timing:
   • "Redraw angefordert in: X ms" ← Request time (should be <1 ms)
   • "Echter GC.drawImage-Dauer: Y ms" ← Paint time (the bottleneck, >30 ms on regression)

Expected: Paint time ~5–10 ms
Actual: Paint time ~50–150 ms

OBSERVED BEHAVIOR

✗ Slider movement causes visible UI stalling
✗ Frequent "Not Responding" issues during zoom operations (on slower machines)
✗ Redraw times increase dramatically as zoom level changes
✗ Performance remains poor even with SWT.HIGH interpolation disabled
✗ Issue persists across multiple Windows builds (10/11)

EXPECTED BEHAVIOR

✓ drawImage() completes in ≤10 ms for typical images (matching 2025-09 behavior)
✓ Smooth, real-time zoom slider interaction
✓ No visible latency or stalling during Canvas repaints
✓ HiDPI scaling applied correctly without performance penalty

ENVIRONMENT DETAILS

• Windows OS: Windows 10 Build 22H2 / Windows 11 Build 22H2
• Display Configuration: Multiple monitors with mixed DPI (e.g., 100% + 150%)
• JVM: OpenJDK 11+ / Oracle JDK 11+
• SWT Build: Any version 2025-12 or later
• Image Format: RGB (24-bit) or RGBA (32-bit)

POTENTIAL WORKAROUNDS

1. Disable Anti-aliasing (Partial, ~10–20% improvement)
   gc.setAntialias(SWT.OFF);
   gc.setInterpolation(SWT.LOW);

2. Reduce Image Size Before Rendering (Effective but lower quality)

   • Pre-scale images to a reasonable on-screen size
   • Trade visual quality for performance

3. Manual Image Caching (Workaround, requires manual implementation)

   • Cache pre-scaled image versions at common zoom levels
   • Re-use cached versions instead of relying on handle lookup
   • Example: Keep 100%, 150%, 200% zoom level variants in memory

4. Revert to SWT 2025-09 (Full mitigation, but foregoes HiDPI improvements)

   • Use SWT version prior to 2025-12
   • Accept lack of newer HiDPI/multi-monitor enhancements

SUGGESTED FIX

1. Implement Zoom-Level Image Handle Caching

   • Cache re-scaled image handles per zoom level
   • Invalidate cache only when image changes
   • Lookup in cache before calling expensive getHandle()

2. Fast-Path for Identity Zoom

   • Detect when zoom level == 100% or native DPI
   • Skip handle re-scaling entirely
   • Call native StretchBlt directly

3. Defer Handle Lookup

   • Move handle lookup out of hot path if possible
   • Compute DPI transformations at Canvas creation, not per-draw
   • Batch related drawImage calls to amortize lookup cost

4. Profiling Integration

   • Add optional logging/profiling hooks for drawImage timing
   • Enable developers to detect regressions early

5. Regression Testing

   • Add performance benchmark tests for large image drawImage
   • Gate commits that touch drawImage/getHandle on performance regression tests

ATTACHMENTS

• SWTZoomPerformanceBugExample.java (reproduction case)
• Performance logs comparing 2025-09 vs 2026-06 behavior
• Windows Event Viewer traces (optional, if deep profiling needed)

SEVERITY & PRIORITY

Severity: HIGH

• Affects all Windows HiDPI systems (increasingly common)
• Direct impact on user experience for any image manipulation software
• Multiple user reports of poor zoom/pan performance

Priority: HIGH

• Regression from known working version (2025-09)
• Root cause identified in commit history
• Workarounds exist but require significant code changes

ADDITIONAL NOTES

• Issue manifests most severely on lower-end machines (longer redraw times)
• Partially improved in 2026-06, but still 5–10x slower than 2025-09
• Similar issues reported in related tools (ImageJ, GIMP) after SWT library updates
• HiDPI support is valuable; performance regression should not be the cost

================================================================================
END OF REPORT

[Bio7]

Here some other OS which were tested:

On MacOSX M1 it works very fast (I guess it is hardware accelerated).
On Linux GTK3 it works slow (tested by a collegue)
On Linux GTK4 it works very fast (tested by a collegue - (GTK4 is hardware accelerated))

[HeikoKlare]

I have futher analyzed and thought about this issue and came to the conclusion that a quite simply fix is probably reasonable to address the relevant use cases:

• [Win32] Store 100% handle when drawing single-zoom bitmap #3429

In case you call Image.win32_getHandle(image, 100) in the snippet before using it for drawImage() operations, you will see that drawing happens fast again. This is because the "persisted" 100% handle is used in case it was created before using any of the drawImage() operations. I think that it makes sense to always store the 100% handle once it is requested, as very like you are in a situation that this specific handle is used again (in particular because you have an image at hand for which just a native 100% version exists). That's not the case for every other zoom.

So, @Bio7, you may want to give that change a try. For me, your snippet performs fine again with that change.

One note on the AI output: while the finding about degraded performance is of course correct and valid, the root cause analysis, the suggested fixes and parts of the workarounds are incorrect (even though suggested fix 2 sounds a bit similar to the fix I proposed). All of them do not properly reflect how the Image class and its interactions with the GC class are designed. So in case my proposal does not prove reasonable, I propose to not follow-up using that AI assessment.

[Bio7]

@HeikoKlare Thanks for taking the time to investigate this further.

On the AI output. I cited it above in case someone uses AI to further analyse this bug (which I done already with Claude) for comparison or hints. Of course everything AI outputs should be reflected critically.

[HeikoKlare]

Yes, I did not want to challenge AI output in general. I also use it for most of my work. As you say, it's just important to reflect it critically, and I wanted to point out that this time the output is rather misleading, to avoid that someone with not so deep knowledge in this code accidentally relies on it.

[Bio7]

I added

Image.win32_getHandle(image, 100)

before the paint operation, removed these options to make the paint operation faster

//gc.setAntialias(SWT.ON);
//gc.setInterpolation(SWT.HIGH);

I also changed the drawImage method to the new method.

However I see not really a speed gain in comparison on my Win11 computer.

Here a animated *.gif as a side by side comparison (left with Eclipse RCP 2026.06, right with Eclipse RCP 2025.06):

(Only when the image is zoomed in the area of circa: 94-105% it is faster)

It would be interesting to get results from other Windows testers because you wrote that with your fix it was fast again.

[HeikoKlare]

You are right. I cannot recap anymore if I had any other changes in place that have affected the results. The precise zoom range in which my previous change had a positive effect was 88% to 112% (as those are the values rounded to 100% zoom).

I have update the referenced PR with a draft for a more complex change. The difficulty is that only the specific image providers know at which zoom the image may be sharply rendered and they have hidden this information pretty well (by intent). But without that information, you can just ask the provider to give you the image (with the negative performance impact we have seen). I have drafted a change that makes the providers expose that information so that it can be used to avoid unnecessary image reloads. The design of the solution in that draft is not good yet, but it might be sufficient for initial testing.