Resolution Independence
A friend of mine loves her new 27 iMac but has complained at how small everything is. Searching around on the net I found that it has about a 109 dpi pixel density. I also saw today that the new Nexus phone has a pixel size of 800x480 (as opposed to my iPhone's 480x320 pixel size), and the two together got me thinking more seriously about resolution independence again. Other than making big icons for my apps, I had pretty much ignored the resolution independence issue. Today I fired up Quartz Debug to set the UI Resolution to a bigger scale, and I am happy that my applications did OK. But how accurate of a test is this compared to real-world resolution independence? Or in other words, is there real resolution independence built into Snow Leopard for apps? Can I (or my friend with her 27 iMac) set a scale factor on an application without using Quartz Debug? Is there something similar for iPhone development? Or is the Xcode mailing list a better place for this question? Thanks, Todd ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Resolution Independence
On Jan 5, 2010, at 2:50 PM, Todd Heberlein wrote: A friend of mine loves her new 27 iMac but has complained at how small everything is. Searching around on the net I found that it has about a 109 dpi pixel density. I also saw today that the new Nexus phone has a pixel size of 800x480 (as opposed to my iPhone's 480x320 pixel size), and the two together got me thinking more seriously about resolution independence again. Other than making big icons for my apps, I had pretty much ignored the resolution independence issue. Today I fired up Quartz Debug to set the UI Resolution to a bigger scale, and I am happy that my applications did OK. But how accurate of a test is this compared to real-world resolution independence? Or in other words, is there real resolution independence built into Snow Leopard for apps? Can I (or my friend with her 27 iMac) set a scale factor on an application without using Quartz Debug? RI, unfortunately, is not yet 100%. My app is fully ready to go; got it done back in the days of Tiger developer seeds. However, my app uses its own UI (no Aqua). Thus, I had full control over graphics (100% vector-based PDF) as well as drawing primitives. Having said that, Quartz Debug is definitely a very useful tool to flush out RI issues. There is no user-level setting currently in the OS; you need Quartz Debug from devtools. My app works at all scaling factors (to include the non-integral ones such as 1.333), but I found that the Aqua UI was not up to the same degree of compliance. Integral scale factors turned out somewhat OK (e.g. 2.0), but you could tell where bitmapped art was still being used. Non-integral scaling factors were awful for Aqua. I was hoping that Leopard would be the debut and then later Snow Leopard, but alas not yet. Is there something similar for iPhone development? No. For iPhone OS, you really should use art in the most optimum format. This is currently PNG (i.e. bitmapped). Scaling things on-the-fly ends up eating cycles which means more power consumption. Granted, not nearly as much power as cellular/network communication, but still a waste. Or is the Xcode mailing list a better place for this question? No, most RI threads have been on this list. Definitely search the archives for other notes or tips/tricks. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Animation geometry, layer hosting, and resolution independence
I am having trouble understanding how Core Animation geometry interacts with NSView geometry in a layer-hosting situation. I have an NSView that hosts a root layer, and it has two sublayers that I need the user to be able to drag each around. I want to be able to convert a mouse coordinate into a point suitable for -hitTest:'ing on my root layer. I can convert from the mouse coordinates to the view's coordinates, but then I am not sure how to proceed. The convertPoint:fromView: method of NSView translates into the bounds rectangle, which is distinct from the view's frame. CALayers don't have this bounds/frame distinction, and I'm not sure whether the view's *frame* or it's *bounds* get applied to the hosted layer. I looked at how GeekGameBoard does it: CGPoint where = NSPointToCGPoint([self convertPoint: locationInWindow fromView: nil]); where = [_gameboard convertPoint: where fromLayer: self.layer]; CALayer *layer = [_gameboard hitTest: where]; ...which is straightforward enough BUT when I use Quartz Debug to double the scale factor, GeekGameBoard breaks, as if mouse movements/locations were halved. How do I convert points between these coordinate spaces in a more savvy manner? I think I get Core Animation's geometry within Core Animation, but I still don't get how it relates to the device and NSView geometry. Given the huge textures Core Animation wants to make when I create sublayers on a layer with a shrinking transform, it almost seems that 1 unit always corresponds to 1 pixel. How does Core Animation's geometry relate to NSView's resolution independent geometry? thanks, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Animation geometry, layer hosting, and resolution independence
On Mar 12, 2008, at 13:13, Jens Alfke wrote: On 12 Mar '08, at 12:13 PM, Nathan Vander Wilt wrote: I want to be able to convert a mouse coordinate into a point suitable for -hitTest:'ing on my root layer. I can convert from the mouse coordinates to the view's coordinates, but then I am not sure how to proceed. There doesn't seem to be any API for converting between the coordinates of a view and its root layer. You could probably do it by getting the root layer's transform property, and then running the point in view coordinates through that. Is this what the new NSView convertPointTo/FromBase: are for? (Described in Leopard developer release notes.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Animation geometry, layer hosting, and resolution independence
On 12 Mar '08, at 2:49 PM, Nathan Vander Wilt wrote: I don't understand what this base coordinate system is (not the window's, otherwise the conversions would likely be offset by the view's position therein, right?). But whatever it is, it seems to be shared by the CALayer. The Cocoa Drawing Guide, under Pixel-Exact Drawing, says: These convenience methods make it possible to convert values to and from the base (device) coordinate system. They take into account the current backing store configuration for the view, including whether it is backed by a layer. In a layer-backed NSView, it seems that the 'device', aka backing store, is the view's CALayer; so these methods will convert to/from the layer's coordinates. I'll go update GeekGameBoard now... —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Animation geometry, layer hosting, and resolution independence
On Mar 12, 2008, at 14:49, Nathan Vander Wilt wrote: I don't understand what this base coordinate system is (not the window's, otherwise the conversions would likely be offset by the view's position therein, right?). But whatever it is, it seems to be shared by the CALayer. I'd appreciate a greater understanding of all this, but those functions seem to be necessary for any coordinate work in the layers that needs to relate to the NSView world. All I know is what's in the release notes. They seem to be using base to mean whatever is providing the pixel grid. In the case of normal views, this is the screen (hence the well-known window to/ fromBase conversion). In the case of layer backed views, it means the backing store. So it sort of makes sense. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Core Animation geometry, layer hosting, and resolution independence
--- Jens Alfke [EMAIL PROTECTED] escribió: On 12 Mar '08, at 2:49 PM, Nathan Vander Wilt wrote: I don't understand what this base coordinate system is (not the window's, otherwise the conversions would likely be offset by the view's position therein, right?). But whatever it is, it seems to be shared by the CALayer. The Cocoa Drawing Guide, under Pixel-Exact Drawing, says: These convenience methods make it possible to convert values to and from the base (device) coordinate system. They take into account the current backing store configuration for the view, including whether it is backed by a layer. In a layer-backed NSView, it seems that the 'device', aka backing store, is the view's CALayer; so these methods will convert to/from the layer's coordinates. Most excellent! Glad to have a documentation reference that seems to guarantee correct behaviour in this situation. Between that an the individual geometry guides, I think I should be able to eventually build a sense for how it all meshes. It'd still be nice to have a single go-to document that describes all the various coordinate systems as they meet in a custom drawn layer hosting view. Maybe some of the individual places could be clearer as well. I hate filing bugs like this against documentation, because I really don't know what would help until I've read it, but I'll try file at least one. thanks much, -natevw __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
