In the case of displaying the splash screen when launching Eclipse or an RCP app, the image initially appears correctly but is inverted after a second or two. AFAICS, this is because the initial display of the splash is done natively in the org.eclipse.equinox.launcher.Main class which calls the org.eclipse.equinox.launcher.JNIBridge method showSplash which then calls the native _show_splash method. Presumably whatever is happening in _show_splash works OK.

But then the trail goes to org.eclipse.ui.internal.Workbench and the method createSplashWrapper. Here is where the Shell's background is set at line 786:

splashShell.setBackgroundImage(background);

Then spinEventQueueToUpdateSplash(display) is called by Workbench#createAndRunWorkbench to dispatch messages which updates the splash Shell. This is where the underlying ObjC message from calling setBackgroundImage is dispatched and the image is painted inverted.

Control#setBackgroundImage only sets the Image object and requests an update. Painting the background image is done in Control#fillBackground. The line that actually draws the background image is at line 1323:

NSColor.colorWithPatternImage(image.handle).setFill();

The code for this call is in org.eclipse.swt.internal.cocoa.NSColor:

public static NSColor colorWithPatternImage(NSImage image) {
    long result = OS.objc_msgSend(OS.class_NSColor, OS.sel_colorWithPatternImage_, image != null ? image.id : 0);
    return result != 0 ? new NSColor(result) : null;
}

And another at line 1345:

NSBezierPath.fillRect(rect);

So, there's either a bug in Apple's code or something has changed and a workaround is needed in SWT code.

I can't do any more than offer this analysis, so please feel free to help. :-)

The same problem with using a Pattern with image:

import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.Pattern;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class ImageTestWithPattern {

    public static void main(String[] args) {
        Display display = new Display();
        Shell shell = new Shell(display);
        shell.setText("Image Test with Pattern");
        shell.setLayout(new GridLayout());
        
        Image image = new Image(display, ImageTestWithPattern.class.getResourceAsStream("splash.png"));
        shell.setSize(image.getBounds().width, image.getBounds().height);
        
        Pattern pattern = new Pattern(display, image);
        
        shell.addPaintListener(e -> {
            e.gc.setBackgroundPattern(pattern);
            e.gc.fillRectangle(0, 0, shell.getSize().x, shell.getSize().y);
        });
        
        shell.open();
        
        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) display.sleep();
        }

        display.dispose();
    }
}

This will be in macOS Sonoma final as the behaviour exists in the Release Candidate.

A self-contained snippet:

import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class ImageTest {

    public static void main(String[] args) {
        Display display = new Display();
        Shell shell = new Shell(display);
        shell.setText("Image Test");
        shell.setLayout(new GridLayout());
        
        shell.setSize(200, 200);
        
        Image image = new Image(Display.getDefault(), 200, 200);
        GC gc = new GC(image);
        gc.setForeground(new Color(null, 0, 0, 0));
        gc.drawText("Hello World", 50, 100);
        gc.dispose();
        
        shell.setBackgroundImage(image);

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

        display.dispose();
    }
}

I'm hoping this can be addressed asap; it will hold up our adoption of this latest release

I'm hoping this can be addressed asap; it will hold up our adoption of this latest release

I've documented my analysis of the problem in the previous comments, but I don't know if this is an Apple bug (I have reported it) or something that needs to change in SWT. It needs someone else to answer that.

I am experiencing the same problem on Sonoma/MacMini M2 Pro. It exists in Eclipse 2023-03 as well as 2023-09.

In addition, the name of the application at the left side of the Menu Bar (just to the right of the Apple icon) says "New Application" instead of "Eclipse".

I am experiencing the same problem on Sonoma/MacMini M2 Pro. It exists in Eclipse 2023-03 as well as 2023-09.

Yes, that's because the problem lies in macOS 14.

In addition, the name of the application at the left side of the Menu Bar (just to the right of the Apple icon) says "New Application" instead of "Eclipse".

Yes, and that has been reported (and fixed) here - #779

One of referenced commits from @enplotz above has a nice workaround for the splash screen if anyone is interested:

knime/knime-product@095c88e

The code flips the image which you can set in the splash handler's background image. I've re-purposed it to use in our RCP app's splash handler:

private Image flipImage(Display display, Image srcImage) {
    Rectangle bounds = srcImage.getBounds();
    Image newImage = new Image(display, bounds.width, bounds.height);
    
    GC gc = new GC(newImage);
    gc.setAdvanced(true);
    gc.setAntialias(SWT.ON);
    gc.setInterpolation(SWT.HIGH);
    
    Transform transform = new Transform(display);
    transform.setElements(1, 0, 0, -1, 0, 0);
    transform.translate(0, -bounds.height);
    gc.setTransform(transform);
    
    gc.drawImage(srcImage, 0, 0, bounds.width, bounds.height,
                           0, 0, bounds.width, bounds.height);
    
    gc.dispose();
    transform.dispose();
    
    return newImage;
}

Note that the method there isFlipBugPresent() doesn't work so you'll have to test for whether the bug is present in another way.

I test for it like this:

if(PlatformUtils.isMac() && PlatformUtils.compareOSVersion("14.0") >= 0) {
    // Flip the image
    shell.setBackgroundImage(flipImage(shell.getDisplay(), shell.getBackgroundImage()));
    
    // We are now responsible for disposing of the new image
    shell.addDisposeListener(e -> {
        shell.getBackgroundImage().dispose();
    });
}

@Phillipus unfortunately the workaround doesn't work. I was testing on pre-Sonoma and seems flip-detection won't do the trick, unfortunately - see discussion ->

• knime/knime-product@517efcf#commitcomment-129894276

@swtdev Yes, that's why I said "Note that the method there isFlipBugPresent() doesn't work so you'll have to test for whether the bug is present in another way."

Lol would help if I'd read the whole comment 🙃

But, it would be better if a Mac expert could say why the image is flipped when calling the native ObjectiveC methods. Perhaps the co-ordinate system changed for colorWithPatternImage?

I suspect that it's related to flipping in Image, see for example

Reason might be even simpler. When application starts, NSView created by native code have isFlipped marked as false, but later, all views created via SWTCanvasView.alloc() have isFlipped marked as true (which is strange, I cannot find reason why). So looks like there is "isFlipped" mix between views and display context

Reason might be even simpler. When application starts, NSView created by native code have isFlipped marked as false, but later, all views created via SWTCanvasView.alloc() have isFlipped marked as true (which is strange, I cannot find reason why). So looks like there is "isFlipped" mix between views and display context

Are you able to determine where this isFlipped is set?

There is another flipped creation of the context in Control:

I have provided a pull-request that fixes both of the snippets in #772 (comment) and #772 (comment)

Ok, well, turns out this is way more complicated and doesn't solve all the issues... In fact, it causes line numbers in the editor to be flipped now.

I found this:
https://developer.apple.com/forums/thread/736618

Looks like we are also in that case 3, as we configure isFlipped:

• SWTCanvasView:
  

  eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/widgets/Display.java

  Lines 2781 to 2799 in 030807a

  	className = "SWTCanvasView";
  	cls = OS.objc_allocateClassPair(OS.class_NSView, className, 0);
  	OS.class_addIvar(cls, SWT_OBJECT, size, (byte)align, types);
  	//NSTextInput protocol
  	OS.class_addProtocol(cls, OS.protocol_NSTextInput);
  	OS.class_addMethod(cls, OS.sel_hasMarkedText, proc2, "@:");
  	OS.class_addMethod(cls, OS.sel_markedRange, markedRangeProc, "@:");
  	OS.class_addMethod(cls, OS.sel_selectedRange, selectedRangeProc, "@:");
  	OS.class_addMethod(cls, OS.sel_setMarkedText_selectedRange_, setMarkedText_selectedRangeProc, "@:@{NSRange}");
  	OS.class_addMethod(cls, OS.sel_unmarkText, proc2, "@:");
  	OS.class_addMethod(cls, OS.sel_validAttributesForMarkedText, proc2, "@:");
  	OS.class_addMethod(cls, OS.sel_attributedSubstringFromRange_, attributedSubstringFromRangeProc, "@:{NSRange}");
  	OS.class_addMethod(cls, OS.sel_insertText_, proc3, "@:@");
  	OS.class_addMethod(cls, OS.sel_characterIndexForPoint_, characterIndexForPointProc, "@:{NSPoint}");
  	OS.class_addMethod(cls, OS.sel_firstRectForCharacterRange_, firstRectForCharacterRangeProc, "@:{NSRange}");
  	OS.class_addMethod(cls, OS.sel_doCommandBySelector_, proc3, "@::");
  	//NSTextInput protocol end
  	OS.class_addMethod(cls, OS.sel_canBecomeKeyView, proc2, "@:");
  	OS.class_addMethod(cls, OS.sel_isFlipped, isFlippedProc, "@:");

• SWTImageView:
  

  eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/widgets/Display.java

  Lines 2854 to 2857 in 030807a

  	className = "SWTImageView";
  	cls = OS.objc_allocateClassPair(OS.class_NSImageView, className, 0);
  	OS.class_addIvar(cls, SWT_OBJECT, size, (byte)align, types);
  	OS.class_addMethod(cls, OS.sel_isFlipped, isFlippedProc, "@:");

• SWTController:
  

  eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/widgets/Display.java

  Lines 2972 to 2982 in 030807a

  	className = "SWTScroller";
  	cls = OS.objc_allocateClassPair(OS.class_NSScroller, className, 0);
  	OS.class_addIvar(cls, SWT_OBJECT, size, (byte)align, types);
  	OS.class_addMethod(cls, OS.sel_sendSelection, proc2, "@:");
  	addEventMethods(cls, proc2, proc3, drawRectProc, hitTestProc, setNeedsDisplayInRectProc);
  	addFrameMethods(cls, setFrameOriginProc, setFrameSizeProc);
  	addAccessibilityMethods(cls, proc2, proc3, proc4, accessibilityHitTestProc);
  	OS.objc_registerClassPair(cls);
  	/* Note that isFlippedProc is used for performance and convenience */
  	long metaClass = OS.objc_getMetaClass(className);
  	OS.class_addMethod(metaClass, OS.sel_isCompatibleWithOverlayScrollers, isFlippedProc, "@:");

• SWTView:
  

  eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/widgets/Display.java

  Lines 3183 to 3187 in 030807a

  	className = "SWTView";
  	cls = OS.objc_allocateClassPair(OS.class_NSView, className, 0);
  	OS.class_addIvar(cls, SWT_OBJECT, size, (byte)align, types);
  	OS.class_addMethod(cls, OS.sel_canBecomeKeyView, proc2, "@:");
  	OS.class_addMethod(cls, OS.sel_isFlipped, isFlippedProc, "@:");

The corresponding native code is

That clearly affects things. I commented out this line and the image displays correctly in the Snippets:

In general looks like flipped property isn't correctly overriden in SWTCanvasView and others (overriding getter is not enough in sonoma probably due SWIFT bindings), class_addProperty should be used