Showing messages 1 through 2 of 2.

• macos x already works like this
  2004-03-21 12:50:03  Ian Griffiths | [View]
  
  
  "Ian, your argument now seems to be that OS X windows aren't scalable (say to 2000%) without loss of quality. This is true of course because OS X uses bitmap images for GUIs."
  
  That's not the whole problem. Even if you do provide scalable image data, Quartz 2D still rasterizes to the native display resolution, leaving the compositor to do bitmap scaling. This is evident in Expose - this is just scaling bitmaps. It is evident when you use the accessibility features of OS X to enlarge the display - again, it just scales up bitmaps. And if you look at the PDF I posted in response to mweiher's PDF, it appears that this remains true even when generating PDFs of a window. Only text remains scalable - everything else comes out in bitmap form even if the source data is in vector form.
  
  
  
  "It'd also be much, much slower for machines with 233Mhz G3 processors that support OS X.
  
  "You can't seriously be suggesting that Longhorn will be completely scalable with no lose. It'd mean that everything would be vectors. Widgets, title bar stuff, window backgrounds."
  
  That is indeed the plan. (Or at least it's what Microsoft is currently telling everyone is their plan. If you don't like that, tell them - the whole reason for the Longhorn preview was so people could see where Microsoft were going early enough to offer feedback before everything is set in stone.) Microsoft aren't planning to convert everyone over to Longhorn - its minimum system requirements will include a graphics spec which today counts as high end. (By the time Longhorn ships, such specs will be mainstream.) So yes, it would be absolutely unusable on old machines, which is why Microsoft have no intention of telling people they have to upgrade - they know it isn't going to work on old hardware. (Although they are apparently intending to support 3 levels of quality of user interface, so it will be able to support older hardware to some extent. But the design means that there will inevitably be limits to how old your machine can be and still have a hope of being useable.)
  
  This does mean of course that applications using Avalon won't run on old machines. This is by design - the whole point of this architecture is that it is intended to last as long as the previous graphics architecture. This inevitably means that old hardware will be left behind. The same thing happened with OS X remember - Apple eventually had to give refunds to people who had attempted to install OS X on systems that were too old. As Apple already discovered, if you want to move forward technically, you have to let go of the distant past. Microsoft already have a transitional API that will let you write for both, and which makes it relatively easy to make applications that can take advantage of Avalon if it's there, but still run if it isn't.
  
  Is it too soon to make such a radical change so dependent on high-performance GPUs? Well I guess that depends on (a) when you think Longhorn will ship, and (b) how soon you think developers will actually start moving over to Avalon. I think the answer to both is "Not any time soon". This stuff really is an awfully long way out - it probably won't become mainstream for another 5 years yet.
  
  (The only reason Microsoft are showing it this early is because their customers have asked them again and again over the years to provide more information on their long term plans.)
  
  
  "First, it'd be REALLY slow on any graphics card or CPU right now to have 400 vector objects on the screen at any given time."
  
  That flies in the face of experience with 3D software. Modern 3D games have far more than 400 vector objects on screen at any given time, and they routinely achieve frame rates of 60Hz. (For example, Quake 3 would have up to 6000 polygons of scenery actually getting rendered in any given frame. And that's after all the culling to make sure that it doesn't even bother trying to draw obscured polygons. So even if you make a conservative assumption that your drawing primitives are actually going to need be broken up into 10 individual operations on the actual GPU, you're still not getting all that ambitious by today's standards.)
  
  With modern GPUs, it turns out that processing large numbers of vectors is not only easily achievable, but likely to be faster than rasterizing in software and then copying the results over. (And also faster than just using bitmaps for everything.) The principal reasons for this are:
  
  

  
  
  • Drawing commands are usually smaller than bitmaps containing the results of these commands, and can therefore be moved around faster
  
  
  • GPUs have incredibly fast fill rates, so it's going to be substantially faster to get a GPU to do the drawing than it is to draw it all on the CPU and then copy the drawing over - regardless of whether you've got PCI express, AGPx4 or AGPx8, an interconnecting bus will never be able to approach the data transfer rates that the graphics subsystem achieves internally.
  
  

  
  
  The Avalon team has a target for supporting displays showing around 10,000 primitives. Given that they already have caching techniques (described in earlier comments in this thread) in place for retaining bitmaps on the graphics card for complex bits of the UI that don't change much, this should be easily achievable - it means that if a given piece of UI gets so complex that it really is faster to move over to bitmaps, they can do that dynamically. (And in practice, they won't have to redraw 10,000 primitives every time anything changes. But even if they did, this doesn't take all that long on a modern GPU.)
  
  
  "Look at the image on the clock window. Also not scalable."
  
  It's a photograph, so you wouldn't expect it to be. That's a piece of UI designed for showing photographs...
  
  But the clock itself IS scalable. It's one of the most immediately visible demonstrations in the Longhorn preview of the advantages of a vector-based UI. That clock can remain visible at all times on the sidebar, and if you resize the tile that contains it, the clock resizes with it. And because it's all vector-based, it looks perfect at any size. And it redraws at the full framerate of the monitor (at least it does on my system) so it looks gorgeously smooth as it does so. Moreover, it does so without significant CPU usage.
  
  The clock must have at least 130 vector elements - each minute has at least 2 (a mark and a shadow), and there are a bunch more for doing the hands, the bezel, and the reflection on the face. And remember, this is a developer preview of the OS - they've got an awful lot of work to do on performance, and even so it all works fast enough.
  
  That clock illustrates the kind of thing you can do with vector-based UI.
  
  (The other stuff you pointed to is all XP imagery. The Longhorn preview given out at the PDC didn't have the new shell - it had a slightly modified version of the old XP shell. This is why all of these icons are bitmap based.)
  
  
  "You seriously expect a GPU to handle typographic layout?"
  
  No, that's why I said "it's pretty unlikely that Avalon will hardware accelerate layout." You pretty much reversed what I actually said there.
• macos x already works like this
  2004-03-22 12:20:26  rosyna [View]
  
  
  You seem to be confusing Direct3d/OpenGL with vector image drawing. For OpenGL and the like (what a GPU accelerates) it is a polygon with no AA (until recently and even then FSAA is crap) with a bitmap texture in it. Have you ever seen any applications that use the video card to render text? It ain't pretty and isn't scalable at all.
  
  And I also produced a widow image (with no code) with an image well. SmileyWindow.pdf. I made the smiley image with Sketch then chose Save a Copy as From the file menu. Format was PDF. Made a new application nib in Interface Builder, added an image well (NSImageView) to the nib, dragged the PDF into the well, pressed command R (to run the nib) and printed the window. I'm not sure how you exported OmniGraffle's image though. Sketch is in /Developer/Examples/AppKit/Sketch/.
  
  " Quartz 2D still rasterizes to the native display resolution, leaving the compositor to do bitmap scaling. This is evident in Expose - this is just scaling bitmaps."
  
  Exposé is *only* doing scaling and repositioning, nothing else. It is not possible to do DPI-level scaling because applications that use QuickDraw would look hideous (they don't support DPI independence) and text may look really messed up as well (when using ATSUI, Text using QD will look screwed up.
  
  However, it is true there is a bug in OS X that causes the window server to not properly interpolate the scaled window image even if it is requested, works fine for subviews though. Also Exposé does it the way it does it because it is faster. OS X doesn't have to redraw a thing neither does the GPU (except it resizes a texture to a smaller size). If it was all vector (and retained), something would have to redraw everything.
  
  "That is indeed the plan. (Or at least it's what Microsoft is currently telling everyone is their plan. If you don't like that, tell them - the whole reason for the Longhorn preview was so people could see where Microsoft were going early enough to offer feedback before everything is set in stone.)"
  
  Then it will fail miserably unless common GPUs get massive 2d acceleration abilities by the time longhorn is released. And with it getting pushed back as much as it is, that might be possible.
  
  "That flies in the face of experience with 3D software. Modern 3D games have far more than 400 vector objects on screen at any given time, and they routinely achieve frame rates of 60Hz."
  
  We aren't talking about 3D operations but 2D operations. Even on the best video card, 2D objects in 3D games look like crap. You can clearly see it in FFXI (a game I sadly cannot put down). 2D and 3D operations are a different beast both logically and by implementation. Because of these differences, I've never gotten into OpenGL. However, I would gladly eat crow if you could show me a 2D OpenGL/Direct3D application that is both pretty, scalable, and fast.
  
  It's a photograph, so you wouldn't expect it to be. That's a piece of UI designed for showing photographs...
  
  And anything that uses bitmap images will look horrible when the DPI of the display goes above the DPI of the image. Especially if that app uses vector art everywhere else.
  
  No, that's why I said "it's pretty unlikely that Avalon will hardware accelerate layout." You pretty much reversed what I actually said there.
  
  I was referring to the comment "You don't consider typography a graphics operation?"
  
  Which I don't... cause it isn't. It requires a lot of math and a lot of cached file access. And I don't think it is wise to make the GPU the main processor of an OS which seems to be what people are ultimately suggesting as of late.
  
  As for the QuickTime conundrum, Quartz does create surfaces for different QT formats, OpenGL, and other things that can be accelerated if it can just composite them together. You can easily notice this if you rotate a window, the surface rotates out of sync with the window and due to a bug in Panther if you take a windowed screenshot of such a window it does not compile the surfaces so they all disappear.
  
  Yes, it is possible to rotate a bunch of windows in OS X at the same time with little to no CPU usage (if you don't code the rotate in a tight loop like I did, that is) if QE is enable. Turn it off and the computer becomes unusable.
  
  And can you make a screenshot of longhorn (any part) that is scalable?