Today I stumbled on a nice problem in a project I’m working on. I have an array with objects where each object has a weight. I then need to pick an object randomly while considering the weights (i.e heavier objects will get picked more often). If you think about this problem a bit you’ll definitely come up with a working solution, but Eli Bendersky took the time to sum it up nicely for all of us.

Thanks Eli!

So was trying to debug my app in the simulator when I got one of these cryptic “Error 14389654: The debugger can’t launch the simulator” messages. Obviously the simulator was already running. Fine, let’s quit the simulator and Xcode, and relaunch them. But then when I hit Command+Q in Xcode I got this frightening error:

Don’t you just love Xcode?

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