views:

638

answers:

1

I'm not really sure, what am I asking...

...but if make layer composites in separate methods, and draw them to the view also outside of the drawRect: method... ...then could my app performance get raised?

I'm actually subclassed a puzzlePiece:UIView class, where the puzzlepiece gets rendered, but the redraw invoked now with setNeedsDisplay since the drawing implementation takes place in the drawRect: method. The app lags.

Can I improve performance if I get rid of the so called drawRect: method?

The thing wants to get implemented: http://gotoandplay.freeblog.hu/

+1  A: 

I think what you want to do here is to have a very single, simple UIView that covers the entire play area. Then put each tile in a CALayer, and attach all the CALayers to the UIView and move them around and rotate them. Then there should not need to be a -drawRect: at all. You'll do all your drawing in your layers, and you should get the best performance that way. CALayer is similar to UIView in principle, but much lighter weight (faster and simpler). CALayer is basically a view that can only draw; it can't handle touches or events. It's parent view has to do that for it. But that let's CALayer be much faster.

Rob Napier
I'm afraid CALayer driven rotations gets that jaggy anti-alias I want to avoid. Maybe I should use CALayers within puzzlePiece views only. Could it be "performance grower"?My anti-alias related post: http://gotoandplay.freeblog.hu/archives/2009/12/08/compactTangram_v13_-_problems_on_altialiasing/
Geri
So CALayer is an NSObject subclass, I may subclass my puzzlePiece from CALayer, and get performance better? Hopeso.
Geri
Correct, and you can still make use of layer rotation. And you can subclass or use a delegate. Start here: http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/CoreAnimation_guide/Articles/ProvidingCALayerContent.html Then I recommend using CGContextFillPath() to draw your path rather than an image (which is causing the trouble), but always draw it in the simplest-to-calculate layout. Then use a transform to rotate it. http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/CoreAnimation_guide/Articles/Layers.html
Rob Napier
BTW, even if you weren't constantly rotating, transforms are very useful. It's often faster and definitely easier to apply a transform to the CGContext (like CGContextRotateCTM) and then draw something simple. Consider an arrow (->) that's pointing to the upper right. It's easier to rotate your CGContext 45˚ and then just draw a arrow pointing to the right. Since you keep changing your rotation, I recommend using the layer transform instead of changing the CGContext transform, though, since this way you don't have to recalculate the path.
Rob Napier
And just one *more* thing :D CGPath is expensive to calculate. If you subclass CALayer, calculate the CGPath one time (in -init probably) and reuse it every time you do have to draw. So you may want an initializer like [TileLayer tileWithCGPath:]. That way all your shapes share the same code, and you only calculate the path once (in the owner of the layer).
Rob Napier
Just thinking about all those pre-rendered textures and the like; one more thing you may try with images is to render them twice as big as they need to be on the screen, then rotate them and scale them. That may overcome your jaggies without losing the textures.
Rob Napier
Hey! That sounds good.And If I'm right minification filtering can be set to kinda verygood.
Geri
And in this way the game-logic, and the "full-screen-rendering" class can be totally independent implementations (connected via properties of course).
Geri
First I'm gonna try the puzzlePiece:CALayer subclassing way, and if it will be still lagging, then try that 200% thing you've mentioned (Then I had the chanche to blend shadows with multiply indetead of simple opacity, and that sound really great). I can't imagine when will I finish all of these... ...but result is promising.
Geri