From cb26faa46c7db9a11a58e1ac21eb2e6879a88384 Mon Sep 17 00:00:00 2001 From: Heiko Klare Date: Mon, 3 Aug 2026 15:45:46 +0200 Subject: [PATCH] Add N&N for resource-efficient and size-consistent Windows image drawing See https://github.com/eclipse-platform/eclipse.platform.swt/pull/3429 https://github.com/eclipse-platform/eclipse.platform.swt/pull/3431 https://github.com/eclipse-platform/eclipse.platform.swt/pull/3459 https://github.com/eclipse-platform/eclipse.platform.swt/pull/3463 --- news/4.41/platform.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/news/4.41/platform.md b/news/4.41/platform.md index 9794d092..38a5e34f 100644 --- a/news/4.41/platform.md +++ b/news/4.41/platform.md @@ -126,6 +126,27 @@ The additional context is particularly useful when `favorite configurations` are ![Last Execution gif](images/LastExcecution.gif) +### Faster and Size-Consistent Drawing of Scaled Images on Windows +
+Contributors + +- [Heiko Klare](https://github.com/HeikoKlare) +
+ +Drawing images at continuously changing sizes using one of the `GC.drawImage()` operations is significantly faster on Windows again. + +Since the 2025-12 release, every `GC.drawImage()` call that scaled an image to a size not used before had to prepare the image for that new size, +even if the very same image content was already available from the previous call. +This slowed down applications that repeatedly draw an image at changing sizes, such as an image viewer with a zoom slider or a view whose content scales with the window size. +Zooming or resizing could stall visibly, with individual drawing operations taking up to ten times longer than before. + +Images are now prepared only when content of a different resolution is actually needed, and the prepared content is retained for subsequent drawing operations. +Zooming and resizing images is thus as smooth as before, while images are still rendered as sharply as possible on HiDPI monitors. + +In addition, images are now drawn at consistent sizes on monitors with a zoom other than 100%, independent of which `GC.drawImage()` overload is used. +Previously, the overload that supports cropping could render an image a few pixels off compared to the other overloads, which was particularly visible for images whose width and height differ substantially. + + ## Debugger ### Resume Other Threads During Debugging