Avalon's Media Integration Layer
There is a new article on MSDN describing Avalon’s Media Integration Layer. The article provides insight into some of the key architectural features that differentiate it from other technologies. Earlier this month, Ian Griffiths also wrote about this layer in his Graphical Composition in Avalon article, focusing on composition. Ian’s article led to a discussion on the differences between Apple’s Quartz model and the Avalon model. The MSDN article provides more insight into the differences that Ian described. Given my experience in Mac development and my limited experience with Avalon, a couple of differences jump out at me.
One of the key differences is that Quartz renders to bitmaps and then does compositing and transformations on those bitmaps. Avalon retains the drawing instructions so that it can rerender content as needed with full fidelity. For example, the Macintosh has a function to zoom in on the screen for accessibility. However, you just get a zoomed desktop. I can imagine that on Longhorn you could get a full fidelity zoom (does this already exist?). It also means that you can do things like animations completely within the MIL layer – the client code does not have to install a timer and rerender.
The other key difference I find interesting is deeper support throughout the OS for resolution independence. At the lowest layer, Quartz is resolution independent, but if you were to run Mac OS X on a 200 DPI monitor, everything would be tiny. There’s no way for an application to know that it’s running on a 200 DPI monitor, and there’s no way it can make things like window titles or standard controls larger. The size of Avalon controls are all specified in real world measurements, not pixels. I remember being disappointed that Apple did not solve this problem when moving to Mac OS X. I think it would have been the perfect opportunity to make this jump and update the APIs. If you’ve ever worked with small Japanese text on today’s monitors, you’d really appreciate the need for higher resolution monitors.
Comments
- Anonymous
March 25, 2004
So did you read all the way to the end of the Mac discussion/rantfest? (The forum system crops comments after a certain level of nesting and you have to click on a 'View' link to see the rest of the thread.)
I was arguing from a disadvantage in the discussion forum, because my Mac OS X experience is somewhat limited - I bought myself a Mac a while ago because I wanted to learn more about its graphics system. I played around a lot, and learned a fair bit, but I've not written any serious software on it.
So I'm wondering whether I made any gaffes in what I said about OS X... How did I do?
(I'm also wondering whether everything the mweiher guy said was quite correct... He seemed convinced that OS X really has solved the resolution independence problem. It doesn't look that way to me, but he seems so sure...)
Oh and to answer your question, you can get a full fidelity zoom in the PDC build of Longhorn within a single window. But the PDC build doesn't have the desktop composition engine - in that build the Avalon compositor isn't being used for the whole desktop, it's just being used inside of windows that choose to use it. So as far as I know you can't do a full fidelity zoom on the whole screen in the version of Longhorn that's currently publically available. (But you can easily test how your application will fare when enlarged, because you can zoom the entire contents of any given window.) - Anonymous
March 25, 2004
The comment has been removed - Anonymous
March 25, 2004
Historically, all Macintosh displays were 72 dpi, and Apple was very strict about this. Over the years, they have finally started shipping higher resolution displays. So, one point is no longer equal to 1/72 of an inch on the screen. There is no way on the Mac for me to create a button that's 1 inch wide without figuring out the resolution of the screen and scaling it.
I completely agree that the Quartz architecture is resolution independent. However, I just wish Apple had built Cocoa and Carbon on top of it to be resolution independent. Both APIs just take integer "points" in their view systems. If they used floating point values instead (like the Quartz subsystems) then you could get some true resolution independence in the UI. The key difference is in the comparison of Avalon to Carbon+Quartz or Cocoa+Quartz. It's too bad that the frameworks built on top of Quartz loose his valuable Quartz feature. Who knows, maybe Apple is adding this already and it'll be out before Longhorn.
For the bitmap/rendering issue, I think it's a terminology issue. Once you "flush" drawing on a context, it ends up as a bitmap, and that's all that the window compositing engine deals with from then on.
I don't think I said anything that contradicts what Marcel Weihler said.
In summary:
1. Quartz is resolution independent, but the layers built on top of them are not, removing the ability to have a resolution independent UI (including controls, window title bars, etc). This is fixable, although it requires changes throughout Carbon and Cocoa.
2. Avalon uses a retained-mode, while Quartz 2D rasterizes things. I think this leads to some interesting stuff like the animations handled by the MIL. I did not claim it was novel, just interesting. - Anonymous
March 25, 2004
You can take Marcel's statements on Quartz's capabilities as authoritative. He's been deep in the guts of Postscript, PDF, and Quartz for at least a decade. Check out his products at metaobject.com.
Ian, regarding your statement: "There’s no way for an application to know that it’s running on a 200 DPI monitor, and there’s no way it can make things like window titles or standard controls larger."
Actually, there is a way for an app to know the DPI of the device it's currently drawing into, but most of the time a Cocoa or Carbon app doesn't care.
Usually, we only care if we're drawing to a screen or a printer, since we may make different choices about what to draw for hard copy (like not printing the background color of a web page, for example.)
Chris, just a minor correction: quartz doesn't assume that one pixel is one point, it's the clients of quartz, Cocoa and Carbon, that make that assumption. Quartz doesn't care, it will render what you tell it to render through whatever device transform you set.
-jcr - Anonymous
March 25, 2004
"Both APIs just take integer "points" in their view systems. "
No, NSPoint is defined as a pair of floats. Apple supports the legacy Quickdraw imaging model, which uses 16-bit integer coordinates, but that has been deprecated for some time now.
NSWindow, NSBezierPath, NSView, and Carbon's HIView all express their coordinate spaces in floating point values, and always have.
-jcr - Anonymous
March 25, 2004
Dan: Cocoa and CoreGraphics both use floating-point coordinates, not integer coordinates.
Thanks for the correction, John. I guess Quartz just renders what it's given into wherever it's told... - Anonymous
March 25, 2004
Oops, you are right, they are floats in Cocoa. The fact still stands that on Apple systems, 1.0 maps to 1 pixel on all shipping macs, no matter what the screen resolution is. Is that not true? - Anonymous
March 25, 2004
On the displays of all currently shipping macs, that is correct. It's worth pointing out however, that any NSView that can display itself can also print or fax itself, which necessarily involves rendering at a different resolution.
-jcr - Anonymous
March 25, 2004
True. To further clarify what I wish the Mac had, is the ability to sensibly handle screens of different resolution. Can everyone agree on that? - Anonymous
March 25, 2004
If you want to handle screens of differing resolutions, it's just a matter of writing the appropriate display driver.
-jcr - Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=8840