Creating an NSRect just to align the origin is a pain. Of course you can do much the same thing with NSView’s -centerScanRect:, but in my experience it’s much more common to need aligned NSPoint values when you’re doing custom drawing. Point.y = floor(y * backingScaleFactor) / backingScaleFactor Point.x = floor(x * backingScaleFactor) / backingScaleFactor [line lineToPoint:NSMakePoint(point.x + pointOffset, 100.0) Īnother common pattern was to use the backingScaleFactor to align a coordinate to the nearest pixel in the view: [line moveToPoint:NSMakePoint(point.x + pointOffset, 0.0) The pixelWidth tells you how wide a single pixel is in points, while the pointOffset can be used to align a coordinate so that it straddles the Quartz drawing point: I found myself using this pattern many times throughout NSView -drawRect: code:ĬGFloat backingScaleFactor = ĬGFloat pixelWidth = 1.0 / backingScaleFactor There are many cases where xScope has to align to a pixel boundary. For example, the position indicator windows need to know if the view they’re hovering over has had its bounds origin shifted. The pain here is that it immediately introduces a dependency between windows and views. The workaround is to make an NSWindow that’s larger than you need and then adjust the bounds origin of the NSViews it contains. The red position indicators are also small windows that point to individual pixels in the ruler window. The best example is with the Ruler tool: the origin of the ruler can be positioned to both even and odd pixels on screen. The next big headache was caused because you can’t set a window’s frame using non-integral points. Yes, kids, that’s what we call a painful fricken’ hack. To deal with the first problem, I used an NSEvent category that clamps +mouseLocation results to valid coordinates.įor the second problem, the only workable solution was to capture the +mouseLocation and then track -keyDown: events so the arrow keys can home in on the destination pixel. The second is that the NSPoint does not contain enough resolution to address every pixel on screen. The first is that mouse coordinates can be reported for coordinates that do not exist on any attached screen. The team at Apple has done some amazing work making sure output looks stunning on the Retina display, but being able to get high-resolution input is definitely lacking. The first gotcha I encountered while doing the Retina update was with mouse input using NSEvent’s +mouseLocation. And that’s where the fun begins… Mouse Input xScope, however, does a lot of work with both pixels and points. Here’s hoping that sharing some of the things I learned along the way will help you with your own Retina work.įor most developers who are working strictly in window points, an update for the Retina display is a fairly straightforward process. The 68k to PowerPC, Carbon to Cocoa, and PowerPC to Intel transitions were no walk in the park, but this update really kicked my butt. As I alluded to on Episode 14 of The Talk Show, this update was harder than most. Today we released an update for xScope that supports the Retina display.
0 Comments
Leave a Reply. |