Window briefly painting black on Xojo 2018 r4 & Mojave

I’m updating from Xojo 2017 r3 to 2018 r4, and am seeing an odd painting artefact on macOS 10.14 Mojave. This doesn’t appear on macOS 10.12, or when building from Xojo 2017 r3. Dark Mode support is turned off.

When I open one particular window, it draw as solid black for about a second before the contents are drawn.

Has anyone else seen this? What’s causing it? And are there any workarounds that I can use?

I’m updating from Xojo 2017 r3 to 2018 r4, and I’m seeing an odd painting artefact when opening one particular window in my desktop project on macOS 10.14 Mojave. This artefact didn’t appear in Xojo 2017 r3, and it doesn’t appear when using 2018 r4 and running on macOS 10.12. Dark Mode support is turned off for this project, and I would prefer not to have to do all of the work involved in enabling it :wink:

When I open this window, it paints solid black for about a second and then paints the normal contents of the window.

Does anyone know what’s causing this? And are there any workarounds?

I have this kind of things not only with Xojo, but also with many other applications.

Xojo 2015r1
Mac OS El Capitan (10.11.6)

Is there anything ongoing which could block the Main Thread, while the Window opens?

I see the same thing. Nothing that would block the main thread.

[quote=430866:@Tom Catchesides]I’m updating from Xojo 2017 r3 to 2018 r4, and I’m seeing an odd painting artefact when opening one particular window in my desktop project on macOS 10.14 Mojave. This artefact didn’t appear in Xojo 2017 r3, and it doesn’t appear when using 2018 r4 and running on macOS 10.12. Dark Mode support is turned off for this project, and I would prefer not to have to do all of the work involved in enabling it :wink:

When I open this window, it paints solid black for about a second and then paints the normal contents of the window.

Does anyone know what’s causing this? And are there any workarounds?

[/quote]
This is caused by the app not yielding enough time for the OS to refresh things. We have the same issue with the IDE when it first opens a project and are slowly working that out ourselves.

I also have (my be related):

When I create a folder (but not only) and type a bit fast its name, sometimes the first character(s) are lost (same with the FireFox URL: the other day I saw ange [angel ?] there and was thinking… then I realized that I typed orange…).

The above is with El Capitan (installed in my internal SSD boot disk), nothing similar (to date) with Mojave (on an external HD).

Thanks, Greg. If someone from the Xojo team is able to post a solution to this thread when you’ve found it then I’m sure that will help anyone else who sees this problem.

Would I be right in guessing that the different behaviour between Xojo 2017 r3 and 2018 r4 would be because Xojo’s new using a different version of the macOS APIs?

Can you try 2018r3, it doesn’t show the issue with the IDE so I think it will work with your app too.

Are you calling window.show? It seems like .show causes the window to display asynchronously… As far as I can tell anyway.

You could just not call .show . Set visible=true in the IDE and just instantiate the window using

w = new window1

If your window has implicit instance set so that you can just call .show to open it, you can use callLater:

xojo.core.timer.CallLater(1, AddressOf window1.Show)
Or since accessing any property of an implicit instance window causes it to open, just use

window1.visible = true

This seems to not have the problem in my tests anyway.

I’m seeing this issue too, and in at least one case I tracked it down to a window making changes to its toolbar in the Window.Open() event - it seemed like the toolbar change triggered a refresh, and since the window wasn’t really Open yet, it was drawn solid black.

When I call a window, the first instruction is window.hide, I do what I need to do from that method, then at the end I have a function similar to James above named “showOnNextCycle”.

Pre 10.10 Yosemite, the macOS used to wait for the window to be ready before showing it. In 10.10, Apple changed it so that the OS would show the window, whether it’s ready or not.

They must have had a good reason to change this behavior, but I have no idea what it was. The long and the short of it, it’s now the developers responsibility to make sure the window is ready before it gets displayed.

The way that I ended up tackling this redraw artefact was to redesign what happens when the window is opened.

In earlier versions, it didn’t matter that initialising & loading data into all of the container controls, etc, on the window might take a second. The window was only drawn when it was ready. Now, it’s drawn as solid black immediately and redrawn when the controls have finished initialising. This is our preferences window, which contained lots of sections and controls.

Staggering the loading of the contents of the window has eliminated the problem:

  1. The only controls that are displayed immediately are the sections list and a progress wheel.
  2. A timer embeds and loads the default preferences panel and hides the progress wheel. This only takes a fraction of a second.
  3. A second timer embeds the remaining preferences panels before the user is going to be able to navigate to them.