Residual/trace in Core Animation & CALayers

I am making an Cocoa app, using Core Animation to create custom UI. However, whenever I drag some layers around, they often leave some "residuals/traces" onto the other layers.

So far, my guess is that it is related to my usage of [setNeedsDisplay]. To my understanding, as I drag a layer around, I don't need to call this method to that layer (as nothing is updated within that layer). But the residuals that left behind are on other layers (so maybe they need to call that method? But then how do I know which layers the dragging mouse has passed over?)

For example, most the drawings are as simple as:

// Block view is a subclass of CALayer
@implementation BlockView

-(void)drawInContext:(CGContextRef)context
{   
    CGRect bounds = CGContextGetClipBoundingBox(context);   
    CGContextSetFillColorWithColor(context, color);
    CGContextFillRect(context, bounds)开发者_Python百科;
}
@end

However, sometimes I there are multiple levels of layers (3 max); but I don't think that's a issue.

I am wonder what could be a cause of this? This problem is difficult to show specific code examples, but some hints or possible guesses are welcome.

A common problem is drawing outside bounds. This can happen if you use [self frame] in your drawing routine, versus [self bounds].

Off the top of my head:

• You could try calling setNeedsDisplay: from the top layer in your hierarchy
• You could try drawing using Application Kit classes and using a different graphics context to do your drawing.

This is a problem I had with UIWebViews sometimes. Simply, the Apple code is not (oddly enough) bug free. I tried hiding the offending views and showing another one, kind of like double buffering, only double-viewing, if you like, as a work-around.

If you are moving (animating) views between two positions, hide one, then show and animate the new one from the old to the new position. Thinking back and analysing a bit, the issue occurred when there is more than one subview of the UIWindow - I am now wondering if it goes away if you encapsulate multiple otherwise top-level views inside a almost-top-level "shell" view - try that too? Your mileage may vary. The bug still manifests to an extent after adding "double-viewing" but the user's perception of the problem being an eyesore was markedly reduced as the artifcats appeared for less time.