Starting Pharo on M2 MacBook makes external 4K display unreadable

[riuttner]

When using my macbook air (15", M2, 2023, Sequoia 15.1.1, 24GB) with a connected 4K display (LG 43BN70U, both tested via USB-C in or DP in), everything works fine as long as I stay within the same resolution on both macbook and external display (desktop extended or mirrored, macbook lid open). When I close the lid of the macbook, as usual the machine switches to the max resolution of the display, in my case 4K. As long as the pharo vm (latest or earlier one of this year) is not started, everything works fine. I can work with all known mac applications without any issue, fullscreen or normal size. However, when I start Pharo main window, after a few seconds (typically after some mouse moves) most of the screen is covered by flickering horizontal black stripes of different sizes somehow converging to one final position and size (only disappearing for some milliseconds when I move the mouse). See photo (showing area not black due to mirror effect enhanced by camera):

Closing pharo makes the screen look normal again.

I have a second equal display showing the same behaviour. A few months ago, with an earlier pharo and MacOS release, I ran into the same issue, first thinking of nothing related with pharo, but just a cable problem (even though I have a high-quality USB-C to DP cable which worked well for windows notebooks to 4K). At that time I always had pharo open when trying, thus not detecting that everything worked as long as pharo is not running. I also tried with a high-speed USB-C cable, the issue remains.

When asking myself today "why is pharo launcher not affected?", I found out that the effect depends on screen position and size of the window drawn by pharo engine:

• If I have the launcher windows somewhere in the top part of the screen, window height smaller than half of screen height, and drag the bottom right corner close to the lower screen boundary, the effect starts and is as bad as for pharo main window.
• If I move pharo launcher to the bottom half of the screen, I can increase the size without bad effect, as long as I do not cross the "half screen height" boundary above with any changed window size.
• If I make main pharo window height smaller than half screen height and keep it in the upper half of the screen, no bad effect can be seen when slightly resizing it.
• Slightly increasing height of main pharo window starts with the bad effect as soon as window height roughly exceeds half screen height. In that case the black area starts with the small vertical size documented by this photo:
  

What I also tried is having pharo main window with a very low height, moving it to a position where its bottom border is slightly above of absolute half screen height. Resizing it then vertically down just a bit seems to start the effect as soon as the "magical line" of half screen height is crossed. In this screnario I can get a black area from left to right (as usual) that is only a few pixels high.

During resize of pharo main window, the contents (including all fonts) looks like proportionally scaled until the resizing ends. At end of resize, the scaled texts disappear and the window is repainted with restored font sizes. Even if this behaviour looks "normal" to me, I report it here just in case it is unexpected for those who implemented the pharo window framework.

[Ducasse]

Thanks for the report.

[Rinzwind]

There’s an issue which looks related: Pharo Launcher issue #699. About the window resizing behavior: see Bloc issue #569.

[riuttner]

@Rinzwind: Thanks for your hints! The maximum refresh frequency for my monitor at 4K is 60Hz. For me, the phenomenon looks like as if pharo forces a certain video mode with a higher frequency than 60, maybe unintentionally because of not setting a certain parameter explicitely. Most probably pharo should (accidentally) change the current video mode at all.

[tesonep]

This a really interesting bug, I started to look at it.
I am so surprised how a single windowed application can do that to the whole system.

[tesonep]

It looks it is a known problem of OSX 15.1 https://discussions.apple.com/thread/255821676?sortBy=rank
But why with Pharo?? I will check

MacBook Pro M1 Pro issue with dual displa… - Apple Community

[tesonep]

Are you using ProMotion refresh rate in the monitors? As they try to use dynamic refresh rate depending of the applications

[riuttner]

Unfortunately this simple solution will not be available for me, as ProMotion seems to only be available for MacBook Pro or Apple Pro Display XDR (see https://support.apple.com/en-us/102297). For my MacBook Air, I do not have any setting for refresh rates.

Hopefully this is not a bug of the kind "we hide our advanced feature for plain hardware, even though it is available internally", and accidentally they turn it on all the time for such hardware ...

Apple Support

Change the refresh rate on your MacBook Pro or Apple Pro Display XDR - Apple Support

You can switch between refresh rates on your 16-inch MacBook Pro, 14-inch MacBook Pro, or Pro Display XDR.

[Rinzwind]

@riuttner Maybe try whether the modified #createDefaultRenderer on SDL_Window that I posted in issue #16454 makes a difference in your case as well.

[riuttner]

@Rinzwind Amazing, many thanks! I tried your proposed fix in class SDL_Window and it works for me:

createDefaultRenderer
	^ self createRenderer: -1 flags: SDL_RENDERER_PRESENTVSYNC

(The difference to original code is that flags value was 0 before.)

The direct test that this fix makes the difference is simple: If I have an open, already fixed main Pharo image and drag my Pharo Launcher window (unchanged launcher image) to almost screen height, the flickering is still occurring. If I close launcher window, leaving main Pharo window open, everything is perfect. The bad behavior does not show up any more, even not on resizing or moving main Pharo window or just using it.

To be on the safe side, I included the same fix in my Windows image, saved, closed and reopened it, and did not observe any change in behavior.

Thus I strongly recommend this fix to be included in main release :)

Thanks again to everybody involved!