GC with Image in unsupported use cases

[ShahzaibIbrahim]

Logging a warning for GC initialized with unsupported use cases.

1. all dynamic images (retrieved via any of the existing providers).
2. all images for which handles in other zoom values have already been created.

Examples

Run this examples with following VM arguments

-Dswt.autoScale=quarter
-Dswt.autoScale.updateOnRuntime=true

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class SWTGCImageExample {
	static final ImageFileNameProvider filenameProvider = zoom -> {
		String path = null;
		switch (zoom) {
		case 150:
			path = "bin/org/eclipse/swt/snippets/eclipse.png";
			break;
		case 200:
			path = "bin/org/eclipse/swt/snippets/eclipse.png";
			break;
		default:
			path = "bin/org/eclipse/swt/snippets/eclipse.png";
		}
		return path;
	};

    public static void main(String[] args) {
    	 Display display = new Display();
         Shell shell = new Shell(display);

         Image image = new Image(display, filenameProvider);
         GC gc = new GC(image);

         // Draw something on the image
         gc.setForeground(display.getSystemColor(SWT.COLOR_RED));
         gc.drawRectangle(50, 50, 100, 100);
         gc.drawText("Hello SWT!", 60, 90);

         // Dispose GC after drawing
         gc.dispose();

         // Dispose image
         image.dispose();

         shell.dispose();
         display.dispose();
    }
}

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class SWTImageHandleExample {
    public static void main(String[] args) {
        Display display = new Display();

        // Create an image using the display
        Image image = new Image(display, 200, 200);

        // Obtain the handle from the Image using win32_getHandle
        long handle = image.win32_getHandle(image, 100);
        System.out.println("Created image handle: " + handle);

        // Initialize GC with the image
        GC gc = new GC(image);

        // Modify the image using GC
        gc.setBackground(display.getSystemColor(SWT.COLOR_BLUE));
        gc.fillRectangle(50, 50, 100, 100);

        // Dispose GC and Image
        gc.dispose();
        image.dispose();

        display.dispose();
    }
}

[github-actions[bot]]

Test Results

   545 files  ±0     545 suites  ±0   31m 50s ⏱️ - 8m 3s  4 377 tests ±0   4 359 ✅ ±0   18 💤 ±0  0 ❌ ±0  16 647 runs  ±0  16 506 ✅ ±0  141 💤 ±0  0 ❌ ±0 

Results for commit 3f2b53c0. ± Comparison against base commit f498ca3a.

:recycle: This comment has been updated with latest results.

[ShahzaibIbrahim]

@laeubi I have added a snippet to demonstrate on how to use Image(Display, ImageGcDrawer, int, int) to load an image to the system and draw watermark over it (supported for all zoom level images.

Also I have again changed the condition to only log an error when using the strict mode. This was done as per @HeikoKlare suggestion since Display#setRuntimeExceptionHandler handler contract states to only use it whenever an exception is thrown by a listener or external callback function and this is not the case here.

[laeubi]

I don't see that anyone will inspect the error log view of tested products

Whenever something goes wrong I go to the error log and I also report incidents from there, others do as well, so I don't see this a general problem.

configure a different handler for runtime exceptions at the display to find such errors or the like

Also SWT can be used standalone so its hard to tell how people actually use it. In any case if no one is looking at the errors, then my initial recommendation stays: simply don't log this. If it is important enough for people, they will do.

[HeikoKlare]

Whenever something goes wrong I go to the error log and I also report incidents from there, others do as well, so I don't see this a general problem.

If we guard this behind strict checks (like we do for all comparable checks), it will only pop-up in the error log if you enable strict checks, and I guess that usually no one does not.

Also SWT can be used standalone so its hard to tell how people actually use it. In any case if no one is looking at the errors, then my initial recommendation stays: simply don't log this. If it is important enough for people, they will do.

The strict checks are an ability for developers to run an application with, as the name says, with more strict checks. You have to explicitly enable them to validate your application (manually or via automated tests) regarding those checks. The information is not that relevant for a consumer of an application (who sees the error log and may use the information to report a bug if it annoys them) but just for developers who can simply activate those strict checks to have further validation of an application. This is the same for the other existing strict checks. So why shouldn't we provide the ability to check an application regarding the risk of imperfect images or why should we introduce a different means of identifying them than the other strict checks we have?

[HeikoKlare]

Thank you! Yes, the N&N is from previous release: https://eclipse.dev/eclipse/news/news.html?file=4.35/platform_isv.html