3 ms·

Core Graphics drawing is actually quite slow. On the Retina iPad, drawing is 4 times as slow and uses 4 times as much memory as the 1st gen iPad, and all the C

Core Graphics drawing is actually quite slow. On the Retina iPad, drawing is 4 times as slow and uses 4 times as much memory as the 1st gen iPad, and all the CPU cores in the world are not going to help you. Having recently ripped out most of my -drawRect: methods, replacing them with custom rendered UIImages, I can attest to the significant performance gains that UIImage gives you. On the Retina iPad, I think it's pretty much mandatory. With that in mind, I think most people are better off using a tool like this to produce PDF data rather than raw CG calls, and use generic code to render that PDF data to a UIImage. PDF data produced by Quartz is going to render exactly the same as raw CG calls. It makes for easier project management, and much better performance. Of course, if you don't need resolution independent graphics, just use png.

Zev 15y ago
Its not that Core Graphics is slow, just that CG doesn't guarantee that drawing will take place on the GPU. It turns out that CG typically prefers the CPU for its its drawing. In comparison, when you load images into a UIImageView, you know that the drawing will be done on the GPU, instead. Quick question: How does UIImage's -drawInRect: and -drawAtPoint: differ?[1] With that in mind, I think most people are better off using a tool like this to produce PDF data rather than raw CG calls, and use generic code to render that PDF data to a UIImage The CGPDFPage* functions that Apple provides are document-oriented (remember: the D in PDF stands for "document"), and don't necessarily work well in all cases, either. A compromise could be to render your CG calls into a context that is then turned into a UIImage that gets cached and stuck into a UIImageView for display. This way, you can do your drawing in CG*, get GPU-backed rendering, and don't have to deal with clumsy PDFs to get images. So, my advice? Click the "buy" button. Drawing in code is just another tool to have. No reason to avoid doing so, if the situation calls for it -- and the trick to any tool is knowing when to use it. 1. If you guessed that -drawInRect is CPU-backed and drawAtPoint: is GPU-backed, pat yourself on the back. Simply having your resources in a UIImage isn't enough to guarantee GPU-backed drawing. And drawing on the GPU isn't enough to guarantee that it will be fast.
- ryanpetrich 15y ago
  drawAtPoint: and drawInRect: both call through to drawInRect:blendMode:alpha: which calls through to CGContextDrawImage. CGContextDrawImage has some optimizations to handle unscaled blends and further optimizations for unscaled blits, but it doesn't use the GPU on iOS. Even if it did, it would be using the GPU to draw into a temporary buffer that would have to be drawn again when the QuartzCore scene is rendered.

Zev 15y ago

Its not that Core Graphics is slow, just that CG doesn't guarantee that drawing will take place on the GPU. It turns out that CG typically prefers the CPU for its its drawing. In comparison, when you load images into a UIImageView, you know that the drawing will be done on the GPU, instead. Quick question: How does UIImage's -drawInRect: and -drawAtPoint: differ?[1] With that in mind, I think most people are better off using a tool like this to produce PDF data rather than raw CG calls, and use generic code to render that PDF data to a UIImage The CGPDFPage* functions that Apple provides are document-oriented (remember: the D in PDF stands for "document"), and don't necessarily work well in all cases, either. A compromise could be to render your CG calls into a context that is then turned into a UIImage that gets cached and stuck into a UIImageView for display. This way, you can do your drawing in CG*, get GPU-backed rendering, and don't have to deal with clumsy PDFs to get images. So, my advice? Click the "buy" button. Drawing in code is just another tool to have. No reason to avoid doing so, if the situation calls for it -- and the trick to any tool is knowing when to use it. 1. If you guessed that -drawInRect is CPU-backed and drawAtPoint: is GPU-backed, pat yourself on the back. Simply having your resources in a UIImage isn't enough to guarantee GPU-backed drawing. And drawing on the GPU isn't enough to guarantee that it will be fast.

ryanpetrich 15y ago
drawAtPoint: and drawInRect: both call through to drawInRect:blendMode:alpha: which calls through to CGContextDrawImage. CGContextDrawImage has some optimizations to handle unscaled blends and further optimizations for unscaled blits, but it doesn't use the GPU on iOS. Even if it did, it would be using the GPU to draw into a temporary buffer that would have to be drawn again when the QuartzCore scene is rendered.