Create high-resolution displays for OS X OK, I lied. Last time I said I'd continue our exploration of symbolic hotkeys. That can wait, though, as since then I found myself buried in the guts of Apple's new CoreUI framework and found a pressing need to talk about it. What exactly is CoreUI, you ask? As you may know, Apple is moving towards a fully-scalable, vector- …
When I first looked at the iPhone libraries I was surprised to find that it's all based on PNG icons, not SVG. Since mobile device screen sizes are likely to change between models and over time I was expecting to find them using something scalable, but no. Here where they do have scalable graphics it's PDF rather than SVG: why? Isn't this sort of thing exactly what SVG was intended for?
Is it KDE4? KDE4 sounded like a layer above what he was talking about (but I could be wrong).
To me it sounded like some newbie with no idea of Apple history (or maybe an oldtimer hoping everyone else had forgotten) had just re-invented a variant on the theme of Display PostScript, which was itself fully scalable, vector based, resolution independent, and would let applications take full advantage of high resolution displays and printers.
Quite how you integrate that with a world of Unix-derived X-based apps is a different question, but Apple have a history of surviving pulling the rug from under their app developers every few years, so maybe this will work too.
Anything else folk would like them to reinvent? Proper clusters for enterprise servers, maybe?
>> When I first looked at the iPhone libraries I was surprised to find that it's all based on PNG
>> icons, not SVG. Since mobile device screen sizes are likely to change between models and
>> over time I was expecting to find them using something scalable, but no.
I don't quite get your reasoning. A mobile phone has a fixed screen with a fixed screen size. If you want to install it on a new model new sized model (not something Apple is showing any sign of doing), surely you would replace the PNGs with ones which are suitable for the new sized screen. I can see any advantage to SVG icons on a mobile phone, especially when you consider all the extra work involved in rendering them.
It's PDF rather than SVG because Mac OS X's underlying graphics engine—Quartz—natively renders graphics in terms of PDF-like streams (it's not actually PDF itself, but an internal representation of the primitives, but it means that displaying a PDF is an utterly trivial operation).
Rendering SVG, on the other hand, is fine in a web browser but horrible for basic UI elements given the architecture.
I presume PNG rendering is far cheaper in terms of CPU cost, and that is something developers are having to think about on low-power devices like the iPhone - it already uses a different UI layer to desktop Cocoa anyway, presumably for similar reasons.
I don't think it's a reinvention of Display PDF - as has been commented, OS X uses PDF-ish in the graphics engine and NeXT did use Display PDF at one point . . . but that is the layer below the construction of UI elements - which were bitmaps within the PDF 'document'.
>Quite how you integrate that with a world of Unix-derived X-based apps is a different question
Cocoa apps aren't X-based, but use the alternative Aqua/Quartz framework - the MacOS implementation of X is separate so this wouldn't affect that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
