Graphics slow on El Capitan

[Sam_Rowlands]

[quote=229400:@Joe Ranieri]Unification of AppKit and CoreAnimation display cycles
AppKit deferred layout and display now occur at the same time as CoreAnimation deferred layout and display. AppKit layout and drawing operations between +[NSAnimationContext beginGrouping] and +[NSAnimationContext endGrouping] will be treated as an atomic unit (this also applies to +[CATransaction begin] and +[CATransaction commit].) This can be used in place of NSDisableScreenUpdates and NSEnableScreenUpdates. The use of these two functions is discouraged. Likewise, it should no longer be necessary to use +[NSWindow disableScreenUpdatesUntilFlush] (its use is also discouraged.)[/quote]
This must be why apps draw black windows, which then go white, or draw shadows long before the content… El Cap really has some weird visual artifacts and issues.

Ironically I’ve been using NSDisableScreenUpdates & NSEnableScreenUpdates to mop up this mess!

[Joe_Ranieri]

[quote=229556:@Sam Rowlands]This must be why apps draw black windows, which then go white, or draw shadows long before the content… El Cap really has some weird visual artifacts and issues.

Ironically I’ve been using NSDisableScreenUpdates & NSEnableScreenUpdates to mop up this mess.[/quote]

It’s plausible, but the times when I’ve seen this happen are when the application is blocking the main event loop. To me this suggests something on the WindowServer side.

[Beatrix_Willius]

I’ve only seen black windows in Xojo and not in my app. Must be doing something right for once - by accident.

[Sam_Rowlands]

@229567:@Joe Ranieri

It’s plausible, but the times when I’ve seen this happen are when the application is blocking the main event loop. To me this suggests something on the WindowServer side.

I see this with my own apps and Apple’s apps. Even with the Apple color picker, often shows a black silhouette with shadow, then after a few seconds shows the color picker, but only when the app is launched.

I guess I need to thread my loading routines, where possible although with Core Image, it’s all deferred until it’s drawn…

[Emile_Schwarz]

How about low available RAM (not enough for doing what is requested) ?
(this is about the black things)

;- or anti IRS measures ? (black things…)

[ChristopheDV]

@229400:@Joe Ranieri

Normally this isn’t a problem because views either aren’t invalidated during a timer callout or the timer periods are long enough that drawing will be handled as usual. Having a timer that invalidates controls and is faster than the display rate is about the only time this starts becoming a ‘problem’.

Do I understand it correctly it is not needed to add an .invalidate inside an action of a Timer because OSX El Capitan already does this by default when the action event is triggered?

[ChristopheDV]

@229556:@Sam Rowlands

This must be why apps draw black windows, which then go white, or draw shadows long before the content… El Cap really has some weird visual artifacts and issues.

I never seen this happen in my apps (and most use a lot a declares for drawing shadows etc). odd…

[ChristopheDV]

@229569:@Beatrix Willius

I’ve only seen black windows in Xojo and not in my app. Must be doing something right for once - by accident.

Yes, when compiling starts, the progress window is black for some seconds. I noticed this too.

[jim_mckay]

You’ve probably already tried this, but try calling fush on CATransaction in the start of the open event of the window. It helps here when I block the main thread in the main window’s paint event (just for testing). Maybe OSX is loading resources after the window is created and before the content has rendered.

[code] Declare sub flush lib “Cocoa” selector “flush” (classref as ptr)
declare Function NSClassFromString lib “Cocoa” (classname as CFStringRef) as ptr

flush(NSClassFromString(“CATransaction”))
[/code]

[Sam_Rowlands]

I started a new thread on Visual Atomicity yesterday (moving it from this one), perhaps you’d like to re-post your solution there, so that they’re kept together?
https://forum.xojo.com/32432-visual-atomicity-in-el-capitan

[Ulrich_Bogun]

What’s the open event in Xojo, technically spoken?
I made the experience in iOS that the Xojo open event is too early to do manipulations on the view content because its dimensions have not been initialized at this time. It works in the debugger but not on a device.

While this is not exactly the issue here, Apple is moving a lot of stuff from iOS to OSX, and very likely the core graphics engine is part of that. When the open event is blocking the first drawing of the content, have you tried if things work better when you attach your code to the hasMovedToWindow: event? In iOS this is the solution to start code when the view has really initialized.