R – NSView leaves artifacts on another NSView when the first is moved across the second

cocoadrawingnsview

I have an NSView subclass that can be dragged around in its superview. I move the views by calling NSView's setFrameOrigin and setFrameRotation methods in my mouseDragged event handler. The views are both moved and rotated with each call.

I have multiple instances of these views contained by a single superview. The problem I'm having is that, as one view is dragged over another, it leaves artifacts behind on the view it's eclipsing. I recorded a short video of this in action. Unfortunately, due to the video compression the artifacts aren't very visible.

I strongly suspect that this is related to the simultaneous translation and rotation. Quartz Debug reveals that a rectangle of the occluding (or occluded) view is updated as another view is dragged across it (video here); somehow this rectangle is getting miscalculated by the drawing engine, so part of the view that should be redrawn isn't.

The kicker is I have no idea how to fix this. I can't find any way to manually specify the update rect in the docs, nor am I sure that's what needs to happen. Any ideas? Thanks!

Best Answer

You might also consider using CALayers instead of views. Unlike views, layers are intended to be stacked with their siblings.

For a possible least-effort solution, try making the views layer-backed; it may or may not solve this problem, but it's worth a try.

Related Solutions

Macos – NSView’s autoresizing behavior

This code

NSView* superView = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 100, 100)];
NSView* subView   = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 100, 100)];
[superView addSubview:subView];

[superView setAutoresizesSubviews:YES];
[subView setAutoresizingMask:NSViewWidthSizable | NSViewHeightSizable];

NSLog(@"subview's frame before resizing: %@", NSStringFromRect([subView frame]));
[superView setFrame:NSMakeRect(0, 0, 200, 100)];
NSLog(@"subview's frame after  resizing: %@", NSStringFromRect([subView frame]));

does give the expected result:

[...] subview's frame before resizing: {{0, 0}, {100, 100}}
[...] subview's frame after  resizing: {{0, 0}, {200, 100}}

Your problem is elsewhere. I expect that one of your container views is not a part of the view hierarchy of the window at the time when the resize occurs.

A good solution for your problem might be the use an NSTabView without tabs, because then all your views are at all times in the window (possibly hidden) and the tabview takes care of the resizing.

Another solution is to put several views on top of each other and use setHidden: to show only one.

Cocoa – n’t I use a cursor rect on a rotated NSView subclass

Yeah, it figures that right after posting my question, the answer would occur to me. It appears as though the hit detection employed by cursor rects operates on simple rectangles only; therefore, if a view with a cursor rect is rotated, the actual cursor rect used will be the smallest rectangle that completely encloses the rotated original rect.

However, I'm leaving this open in case there are other undesirable side effects I'm not seeing.

Related Topic

R – How to Rotate a CALayer-backed NSView subclass