Update: When writing this I wasn’t aware of CGRectIntegral() which is by far a better choice (as QC explains in the comments).
If you ever did extensive drawing with quartz, or any dynamic UI placement on the iPhone, you probably stumbled on this as well. I first saw it when drawing the oval shapes that show your priority in Matalot. The drawing code was very simple. Add an oval path, then fill + stroke. But to my surprise, when testing on the simulator the drawing was blurred. On my iPhone’s small screen it was less obvious, but blurred as well.
At first I thought something is wrong with my eyes. But then I added another instance of my view which rendered perfectly. There I was, with two instances of the same view, one blurred and one with the crisp anti-aliasing you’d expect from quartz. WTF?!
After many sleepless hours I suddenly remembered an article I once read about font rendering. In that article they discussed the rendering issues and how Windows draws fonts differently from OS X. Writing about this made me look up this article. It’s a very interesting reading, especially if graphics is your thing. Also be sure to read the linked articel about sub-pixel rendering.
Back to the subject, Apple and many others are using sub-pixel rendering to get beautiful anti-aliasing. Apple also prefers to stay loyal to the original drawing, even at cost of slight blurring. So perhaps my drawing just falls under this category? At this point I stepped back and checked out the exact placement and size of my views. And guess what, the blurred one was placed at non-integer pixels.
It turns out that quartz rendering gets blurred when placed at non-integer pixels! Rounding each pixel of the blurred view’s frame magically drew a beautiful result. How did I end up with non-integer values in the first place you ask? Simple. Placing a view at otherView.bounds.size.width / 2.0 may result in something like 45.5, and BOOM! You got blurred result.
Here is a quick function I use in order to make sure my views’ frames are with integer values. Feel free to use it as you wish.
static inline CGRect DPIntRect(CGRect rect) { #if CGFLOAT_IS_DOUBLE rect.origin.x = lrintl(rect.origin.x); rect.origin.y = lrintl(rect.origin.y); rect.size.width = lrintl(rect.size.width); rect.size.height = lrintl(rect.size.height); #else rect.origin.x = lrintf(rect.origin.x); rect.origin.y = lrintf(rect.origin.y); rect.size.width = lrintf(rect.size.width); rect.size.height = lrintf(rect.size.height); #endif return rect; }
I’d love to hear if you also experienced this, especially if you have a different solution 
I am not sure how this is better than CGRectIntegral().
This code could move the right and bottom edges by up to a whole pixel, but it would never move the left or top edges by more than half a pixel. That is a strange bias to have.
Finally, there’s a lot of potentially costly type conversion going on: first from double to long double, and then from long to double. Using rint() (and rintf() for 32-bit) would avoid that. Using round() and roundf() would also avoid the dependency on the prevailing rounding mode.
You’re absolutely right. This is just a function I hacked up when I noticed the blurred drawing. I actually discovered about CGRectIntegral() slightly later, and recommend using that.