4 ms·

I don't really know what graphics you're drawing in your app, but this approach will kill the performance of anything that relies on the GPU. Since you're only

by nglevin 14y ago

I don't really know what graphics you're drawing in your app, but this approach will kill the performance of anything that relies on the GPU. Since you're only using Core Graphics, this is acceptable. Core Graphics only has a CPU implementation on iOS. Core Animation has a CPU implementation that only gets activated under certain conditions; otherwise, it renders through the GPU by default. If you're planning on using CA... - outside of -drawRect:, - with no shadows or masks (transparent gradients, for instance,) - without text (CATextLayer, UILabels, Core Text, UIFont,) - with -shouldRasterize: assigned to NO (the default,) - without overriding -drawInContext: (which draws a CALayer's content to a CGContext,) - with any OpenGL code at all, ...you're going to quickly end up in the land of seconds per frame instead of frames per second.

eduardordm 14y ago
"Core Graphics only has a CPU implementation on iOS." No. :D
- nglevin 14y ago
  Would you care to elaborate, rather than be glib? QuartzGL runs all Core Graphics on the GPU[1]. It's only available on OS X. If you can show me evidence that some API on iOS runs Core Graphics on the GPU, I'd be happy to know. I do a fair amount of work running Core Animation, CG and OpenGL at the same time, so it would be a big help. [1] - http://www.cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing-on-graphics.html http://www.cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing...
  - eduardordm 14y ago
    This really isn't the place, but: You are confusing the composition and the actual rendering. When you use CG you are composing in the cpu but the actual result is always rendered by the gpu, there is no such thing as rendering by cpu in ios devices. When using opengl the composition and rendering will happen in the gpu. But this is not really important for static objects like buttons, they are built once, unless use force changes, it wont touch the cpu (written on a phone, sorry about typos) For instance, this is 100% gpu: http://developer.apple.com/library/ios/ipad/#documentation/GraphicsImaging/Reference/CGAffineTransform/Reference/reference.html%23//apple_ref/doc/c_ref/CGAffineTransform http://developer.apple.com/library/ios/ipad/#documentation/G...
    - nglevin 14y ago
      This is the place. It's HN! I have a strong suspicion that CGAffineTransform and its associated methods are calculated through the ARM NEON co-processor. I don't see anything in the documentation you provided that mentions the GPU. It _could_ be done in a vertex shader on the GPU, but looking at the API, the use of Rotation, Scale and Translation methods seems more consistent with it being done on the CPU or the CPU's floating point co-processor. Otherwise, there would be something equivalent to glBegin() or glEnd() to prep calls to update the uniforms for the shaders and render to the frame and render buffers, much like CA's transaction based API for animations - the block based API is similar, too.[1] Frankly, switching to a shader just to do rotation/scaling/translation is a bit much, and better left to the CPU in most cases. Andy Matsuchak of Apple claims that "When you implement drawRect or draw with CoreGraphics, you're using the CPU to draw, and that drawing will happen synchronously within your application. You're just calling some function which writes bits in a bitmap buffer, basically."[2] That is rendering. Unless you're confusing rendering with compositing layers, the act of blending several CALayers/UIViews together. The compositing bit is completely dependent on how you opted to draw your layers; some can be composited on the CPU, others on the GPU. I've listed all the ways that a layer can be composited on the CPU, it's just something to watch out for. [1] - I'll grant you that CA has an implicit animation API, but CA also has a much more elaborate system of keeping current state and projected state in place. CA has layer trees for each to avoid having to block the CPU and wait on the asynchronous GPU for results, which CG doesn't. [2] - http://robots.thoughtbot.com/post/36591648724/designing-for-ios-graphics-performance#comment-720533654 http://robots.thoughtbot.com/post/36591648724/designing-for-...

by nglevin 14y ago

eduardordm 14y ago

"Core Graphics only has a CPU implementation on iOS." No. :D

nglevin 14y ago
Would you care to elaborate, rather than be glib? QuartzGL runs all Core Graphics on the GPU[1]. It's only available on OS X. If you can show me evidence that some API on iOS runs Core Graphics on the GPU, I'd be happy to know. I do a fair amount of work running Core Animation, CG and OpenGL at the same time, so it would be a big help. [1] - http://www.cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing-on-graphics.html http://www.cocoawithlove.com/2011/03/mac-quartzgl-2d-drawing...
- eduardordm 14y ago
  This really isn't the place, but: You are confusing the composition and the actual rendering. When you use CG you are composing in the cpu but the actual result is always rendered by the gpu, there is no such thing as rendering by cpu in ios devices. When using opengl the composition and rendering will happen in the gpu. But this is not really important for static objects like buttons, they are built once, unless use force changes, it wont touch the cpu (written on a phone, sorry about typos) For instance, this is 100% gpu: http://developer.apple.com/library/ios/ipad/#documentation/GraphicsImaging/Reference/CGAffineTransform/Reference/reference.html%23//apple_ref/doc/c_ref/CGAffineTransform http://developer.apple.com/library/ios/ipad/#documentation/G...
  - nglevin 14y ago
    This is the place. It's HN! I have a strong suspicion that CGAffineTransform and its associated methods are calculated through the ARM NEON co-processor. I don't see anything in the documentation you provided that mentions the GPU. It _could_ be done in a vertex shader on the GPU, but looking at the API, the use of Rotation, Scale and Translation methods seems more consistent with it being done on the CPU or the CPU's floating point co-processor. Otherwise, there would be something equivalent to glBegin() or glEnd() to prep calls to update the uniforms for the shaders and render to the frame and render buffers, much like CA's transaction based API for animations - the block based API is similar, too.[1] Frankly, switching to a shader just to do rotation/scaling/translation is a bit much, and better left to the CPU in most cases. Andy Matsuchak of Apple claims that "When you implement drawRect or draw with CoreGraphics, you're using the CPU to draw, and that drawing will happen synchronously within your application. You're just calling some function which writes bits in a bitmap buffer, basically."[2] That is rendering. Unless you're confusing rendering with compositing layers, the act of blending several CALayers/UIViews together. The compositing bit is completely dependent on how you opted to draw your layers; some can be composited on the CPU, others on the GPU. I've listed all the ways that a layer can be composited on the CPU, it's just something to watch out for. [1] - I'll grant you that CA has an implicit animation API, but CA also has a much more elaborate system of keeping current state and projected state in place. CA has layer trees for each to avoid having to block the CPU and wait on the asynchronous GPU for results, which CG doesn't. [2] - http://robots.thoughtbot.com/post/36591648724/designing-for-ios-graphics-performance#comment-720533654 http://robots.thoughtbot.com/post/36591648724/designing-for-...