iphone - What is faster? Drawing or Compositing? -


i make extensive use of -drawrect: nice animations. timer tries fire 30 times per second -setneedsdisplay, feels 20 times. can't use -setneedsdisplayinrect: because animation covers entire thing.

would take of drawing operations out of -drawrect: , move them subview? -drawrect has less then, instead os have more work compositing views.

is there rule of thumb 1 more worse? remember apple text claimed core animation doesn't redraw during animation. secret of speed? using subviews in animations?

much of similar my answer your other question:

compositing faster, far. on iphone, content drawn calayer (or uiview's backing calayer) using quartz drawing calls or bitmapped image. layer rasterized , cached opengl texture on gpu.

this drawing , caching operation expensive, once layer on gpu, can moved around, scaled, rotated, etc. in hardware-accelerated manner. gpu has while layer animating composite other onscreen layers every frame. why core animation can 50 layers animating around screen @ 60 fps on oldest iphone models.

layers , views redraw when prompted, or if resized when needsdisplayonboundschange property set yes. drawing system set way because of how expensive redraw , recache layer contents. if can, avoid redrawing layer content regularly, instead split layers or views can animate around individually using core animation. if need animate changing shape, cashapelayer, makes more efficient redrawing every frame.

as worst case, yes, can take portions of view static , move them 1 view, have subview has changing portion of drawing within it. performance won't great, better if had redraw within view. compositing overhead negligible compared expense of drawing.


Comments

Popular posts from this blog

javascript - Enclosure Memory Copies -

php - Replacing tags in braces, even nested tags, with regex -