Colors are inverted on Apple M1 chip

A user of my application has a computer with an Apple M1 Max CPU. When they launch the application, the red and blue channels are swapped.

Here’s what the same picture looks like when the image is Photoshopped to swap the red and blue channels (so it appears correct).

It appears this also happens in older versions of Minecraft when using an Apple Silicon chip. It is also mentioned that the bug only exists in Minecraft versions before 1.6. I wonder if an OpenGL or LWJGL upgrade causes this to not appear in new Minecraft versions?

My application uses org.jmonkeyengine:jme3-lwjgl:3.5.2-stable. LWJGL 3 does not seem to work on their computer.

Does there exist a known fix that will display the colors correctly?

1 Like

LWJGL 3 does not seem to work on their computer.

Can you confirm if it works on other OS? Also, can you provide the full stack trace of the error?


Not really a mac guy. Is the M1 only in laptops? I’m curious if he is just displaying on his laptop or possibly to an external monitor?

Found this sort of old thread with color issues as well – MacBook Air M1 external monitor issue

Are things displaying green properly?
Does he have the issue any other time or just when he is Travis Barker? (in the drum app :melting_face:)

Probably, JME requests the buffer in one order (RGB) and gets a buffer in BGR (or vice-versa) and nothing complains about it. (Or it did complain to the console and that information was not captured.)

I can’t speak to why.

Someone tried to run the new Mythruna engine on an m1 (Mythruna still uses lwjgl2) and the colors were correct… it failed later in one of my custom shaders. Up to that point, the UI and stuff seemed to be the right color.

I don’t know what’s different about my setup, though.

Only LWJGL3 is supported on Apple m1.

I’ve downloaded your app and it seems that you are launching it with an x86_64 JVM as opposed to the M1 JVM, this will run it under the Rosetta compatibility layer (as Apple m1 cannot run x86 applications natively), this explains why you can run it with LWJGL2, however it might be related to the issue you are experiencing.

Generally i would suggest to look into what is preventing your app from running on LWJGL3, since LWJGL2 is not being maintained anymore.

Some possible things to look into:

  • Remove internal calls to LWJGL2 methods and classes (eg Display.*) from your app
  • Ensure the M1 JVM is used on Apple M1
  • Ensure the M1 (mac arm) natives are included in the final jar
  • Ensure the jar is launcher with -XstartOnFirstThread (this is required for macos when using LWJGL3) or see workaround below

-XstartOnFirstThread & Workaround

if your app uses AWT calls, as it seems it does, it will hang forever, since the windows manager used by LWJGL3 doesn’t like when its render loop is shared with other libraries (in this case awt).
To fix that you either need to replace AWT calls with something else, or when not possible, you can try to add this code before the start() call


This is a new workaround in lwjgl3 and might cause some issues, that’s why we aren’t using it in the engine yet.


Thank you everyone for the information! I concur that it is best to update to LWJGL 3. I’m having my M1 user test using an ARM JDK.


hope it works! good luck!

Okay, after performing the following changes, my user only sees a black screen now.

  • Run using the Azul Zulu macOS ARM 64-bit JDK
  • Run with -XstartOnFirstThread
  • Move execution of JME application to main thread

At this point, I’m stumped. I think I’ll have my M1 tester try running a “hello world” JME application just to make sure that no other dependencies or frameworks I’m using are interfering. Just figured I’d post an update here since I’m sure there’s at least one other person who’s having a similar issue.

1 Like

Okay, my M1 user was able to get the basic “hello world” application to run. It required disabling the settings window app.setShowSettings(false) (I’m assuming this is necessary because—as mentioned—AWT and LWJGL3 won’t mix) and executing on first thread -XstartOnFirstThread. This doesn’t explain why my application still shows a black screen, but I think my next plan is to try experimenting with adding


and seeing how that goes.

1 Like

FYI, JME has unsolved issues with graphics on Apple Silicon such as the M1. For instance: