Mavericks: Garbage briefly appears on window resize

[Wowfunhappy]

This should, at long last, be the last Mavericks-specific issue!

When resizing a window from the right side, garbage briefly appears until it can fully redraw itself.

Window.Resize.Garbage.mov

I was able to fix this via code injection by setting [NSView setWantsLayer:true]. This didn't work on App Windows for some reason, but I'm hoping that's just down to how I was injecting the code.

[blueboxd]

Implemented as viewWillStartLiveResize in NativeWidgetMacNSWindowBorderlessFrame.
Garbage appears to be alleviated, but background ghost seems still remaining.
Is this acceptable?

[Wowfunhappy]

It's definitely an improvement, but when I injected it it worked much better, actually drawing a gray background. Maybe there's a different instance of NSView which needs it?

#import <Cocoa/Cocoa.h>
#import <AppKit/AppKit.h>
#import "ZKSwizzle.h"

@interface myNSView : NSView
@end

@implementation myNSView
- (void) viewWillStartLiveResize {
    [self setWantsLayer:true];
    ZKOrig(void);
}
@end

@implementation NSObject (main)
+ (void)load {
    ZKSwizzle(myNSView, NSView);
}
@end

[blueboxd]

I got it, I'll try to find another view to apply setWantsLayer.
Please wait a while.

[Wowfunhappy]

An alternate fix might be to set:

[NSView setLayerUsesCoreImageFilters: true];

This also works for me via code injection, although admittedly so did the last one. However, I think this might be addressing the actual problem more directly:

https://developer.apple.com/documentation/appkit/nsview/1483576-layerusescoreimagefilters?language=objc

In macOS 10.9 and later, AppKit prefers to render layer trees out-of-process but cannot do so if any layers have Core Image filters attached to them. Specifying YES for setLayerUsesCoreImageFilters lets AppKit know that it must move rendering of the layer hierarchy back into your app’s process. If the value of this property is NO, adding a filter to the view’s layer triggers an exception.

[Wowfunhappy]

Scratch that, setLayerUsesCoreImageFilters works in a VM without graphics acceleration, but not in my real OS. Although it does have an effect—when set, the "garbage" appears to come from the page I'm currently viewing, rather than from e.g. my desktop background.

[blueboxd]

Thanks! I'll try that later.
But which view is responsible...? Still unknown.
I tried few views to apply setWantsLayer, but rendered very flickering or has no effect.

[Wowfunhappy]

To be clear, don't try using setLayerUsesCoreImageFilters . I spoke too soon, it only works in a VM, presumably due to the lack of graphics acceleration.

The view, wherever it is, appears to have the class name BrowserWindowFrame, because injecting this worked:

@implementation myNSView
- (void) displayIfNeeded {
	if ([ [self className] isEqualToString:@"BrowserWindowFrame" ]) {
		[self setWantsLayer:true];
	}
	ZKOrig(void);
}
@end

[blueboxd]

Oh, sorry for my misunderstanding.
And thank you for the view class.
I applied setWantsLayer to BrowserWindowFrame, the ghost has gone, but some glitches appeared on the corners of the window.

I think this should be avoided.
(Maybe there are other views to be applied...?)

[Wowfunhappy]

I think this should be avoided.

Agreed! Very odd how it's different when I swizzle it.

[Wowfunhappy]

I applied setWantsLayer to BrowserWindowFrame, the ghost has gone, but some glitches appeared on the corners of the window.

Aha, after some more testing I think these corner glitches are lion-only! That's why they happened for you but not me. Are you seeing the issue in 10.8+?

[blueboxd]

Hmm, on my VMs, corner glitches only occur on 10.9...
Applied to BrowserWindowFrame as below (in browser_native_widget_window_mac.mm).

- (void) viewWillStartLiveResize {
  [self setWantsLayer:YES];
}

- (void) viewDidEndLiveResize {
  [self setWantsLayer:NO];
}

I think glitches are caused by setWantsLayer:NO on viewDidEndLiveResize, but without disabling setWantsLayer, content view begins flickering...

[Wowfunhappy]

Huh. Odd. 🧐

Does it change anything if you put it in displayIfNeeded instead? That's what my working code does.

[blueboxd]

No change:pensive:
No resizing garbage, no corner glitches, but very flickering.

[rmottola]

I have such a problem on 10.7 Lion. The garbage appears not only on resize, but on fist display of a window. It is clearly just "leftover data" containing pieces of the screenbuffer unrelated. On startup Chromium make take some time to open and the garbage can clearly seen, on resize it is more a glitch.

[Wowfunhappy]

@rmottola Does the problem go away if you use #25?

[rmottola]

@Wowfunhappy It improves partially. On first load the window is grey and not filled with garbage, on resize instead it may contain some garbage that quickly disappears.

[Wowfunhappy]

Interesting! So setWantsLayer behaves differently on Lion than on Mavericks... I suspect the reason it works at all is a side effect of something else that gets changed, but I wish I knew what!

Edit: Or maybe it even has something to do with the order things are rendered? Since it causes graphical glitches on the corners when not added via code injection...

[rmottola]

I have no idea, I only have 10.7 - I just moved back to regular builds, v100 seems a little bit better (except these glitches, which have also been there in older versions of Chrome Legacy, just reported them now). I don't know what code injection here means, it looks to me as added view area that is not initialized and gets random framebuffer memory.
On startup I experience long delays up to "almost total" system (whole mac) when windows are grey, then they start drawing. It is not regularly reproducible, but could be related.

[pjpreilly]

I see this always on launch with multiple windows (with multiple tabs), I can hasten the drawing by opening Task Manager (which draws just fine) & killing the GPU process.... takes a few times or maybe its just the timing but the GPU process dies & restarts & the windows begin drawing.
osx Lion on macbook 4,1

[scrutinizer11]

Bringing the topic from the dead, the image jagging has occurred just now, version 109.0.5414.119.1, OS X Mavericks

https://streamable.com/mhitph