Many people never touch interface builder and write all their views from scratch, but in that case you still have the choice between compositing your view using subviews and overriding drawRect with drawing calls.
Many people overestimate how expensive a view is to lay out, and jump straight into code (I'm as guilty of this as anyone else), without actually stopping to see how nibs perform, due to misunderstanding some part of the pipeline.
Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.
Yup. Fun times. Glad we're not there anymore. And given AT&T gives away 3GS's for free, I'd have to agree that the topic's moot and go on to say that it isn't worth the time or effort to support a device that no one has anymore ;)
..but if you have a source on that I'd appreciate a link
Add a log to -layoutSubviews of your cell subclass, and look at how often it gets printed out when you scroll.
If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.
Go far enough back, and everything UI-related is OpenGL. CoreGraphics, however, is not built directly on top of OpenGL. It's part of Quartz, (specifically, QuartzGL). QGL on Mac can use either CPU-backed or GPU-backed drawing. On Mac, QGL defaults to CPU-backed drawing, but an app can use the GPU backing instead, by setting QuartzGLEnable to true in Info.plist. This option isn't available on iOS. You're stuck with CPU, only, for CG.
Many people overestimate how expensive a view is to lay out, and jump straight into code (I'm as guilty of this as anyone else), without actually stopping to see how nibs perform, due to misunderstanding some part of the pipeline.
Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.
Yup. Fun times. Glad we're not there anymore. And given AT&T gives away 3GS's for free, I'd have to agree that the topic's moot and go on to say that it isn't worth the time or effort to support a device that no one has anymore ;)
..but if you have a source on that I'd appreciate a link
Add a log to -layoutSubviews of your cell subclass, and look at how often it gets printed out when you scroll.
If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.
Go far enough back, and everything UI-related is OpenGL. CoreGraphics, however, is not built directly on top of OpenGL. It's part of Quartz, (specifically, QuartzGL). QGL on Mac can use either CPU-backed or GPU-backed drawing. On Mac, QGL defaults to CPU-backed drawing, but an app can use the GPU backing instead, by setting QuartzGLEnable to true in Info.plist. This option isn't available on iOS. You're stuck with CPU, only, for CG.