Showing messages 1 through 6 of 6.

• macos x already works like this
  2004-03-21 14:39:30  Ian Griffiths | [View]
  
  
  "Illustrator does not use Quartz."
  
  Fair enough - my mistake.
  
  Can you show me an application that illustrates zooming in on vector imagery in OS X that does use Quartz then? I'd like to be able to see a proper side by side comparison. What about Omni Graffle? Is that using Quartz 2D? That only seems to manage about 4 redraws a second if I hammer on the mouse button using the zoom tool. It's not keeping up with the mouse clicks for a relatively simple drawing. (The terrible horse drawing I posted earlier.) This suggests that it isn't going to be good enough for a smooth (as in full field rate video playback smooth) zooming.
  
  
  "The dispute is not (a) wether OS X has such a mechanism, it doesn't, but (b) wether or not such a retained vector-level representation is required for higher DPI displays."
  
  *cough* Actually originally it was whether "macos x already works like this" - hence the subject line of the thread.
  
  So do you agree that Mac OS X does not already work like this?
  
  But yes, the debate certainly seems to have shifted to whether its desirable to have a retained vector architecture. One of the subtopics is whether it's necessary for high-DPI.
  
  
  "Instead of showing (b), you keep showing (a) and apparently somehow thinking you're done."
  
  I'm trying to show both. If you'll agree that (a) is true (Mac OS X doesn't work like this), I'll stop banging on about that and concentrate on (b).
  
  
  "3. Drawing engine vs. UI resolution independence.
  
  "You rightly observe that having one doesn't imply the other. Then why on earth do you keep saying the opposite, that a particular type of API (retained vectors within the graphics API) is required?"
  
  Well, what I said was this: "Just because your drawing API is resolution independent doesn't mean your GUIs are."
  
  The corollary of that would be "If your drawing API is not resolution independent, this means your GUI won't be."
  
  I think both of those statements are true - do you disagree?
  
  The problem I'm perceiving with Quartz is that only part of it is resolution independent. (And as I've always said, this is just based on my own experiments, and what the documentation says.) Quartz 2D meets the minimum requirement - it is resolution independent. But it plugs into something which is not - the Quartz Compositor.
  
  I am hypothesizing that this is a problem, because it will cause UIs to be non-scalable in practice. Your earlier post where you showed a window in a PDF is consistent with my theory (but doesn't prove it) because it was just a bunch of bitmaps in a file.
  
  My thinking behind this theory is that unless *everything* that must be done to render a window is resolution independent, you don't have a completely resolution independent system. And given that (a) you can mix Quartz 2D, Open GL and QuickTime into a window, and (b) the only documented part of Apple's architecture capable of combining the output of these three things is the Quartz Compositor, and (c) the Quartz Compositor is pixel based, it seems like there's a problem. (And the PDFs we have both managed to produce so far seem to exhibit the problems you would expect to see if I'm right. As do on-screen whole-window scaling effects like Expose. Both of these seem to be using bitmap-based scaling in practice.)
  
  
  Do I think that retained vectors are absolutely the only solution for high-DPI? I will concede that it may not the only possible solution. I therefore recant my claim that "you absolutely need this for high-dpi displays to be supported automatically for all applications." Looking back at that, this was a blanket statement. I probably can't prove that other techniques do not exist. (Although I will maintain that *something* has to retain a non-bitmap representation somewhere. But I don't think that's controversial.)
  
  This doesn't alter the fact that I stand by my original claim:
  
  "as far as I know, Quartz doesn't have a good way of dealing with high-dpi displays"
  
  I have yet to see any concrete evidence that Quartz has solved this problem - I merely know that it has some of the necessary ingredients. If a resolution-independent drawing API was all you needed for resolution-independence, Windows would have had everything it needed for resolution-independence on the day that Windows NT 3.1 shipped - GDI32 is a resolution-independent API.
  
  And yet Windows has problems with resolution independence. The pixel-based composition is one of the causes of problems in Windows. So this is why I am worried about Quartz. It might have the ingredients for success, but it also appears to have the ingredients for failure.
  
  So when you said: "It seems you understand (and have understood) that Quartz 2D has no problem whatsoever producing higher resolution output and will therefore have no problem driving higher resolution displays."
  
  I don't really go along with everything after the "and will therefore".
  
  Looked at in isolation, Quartz 2D has everything it needs to drive a high resolution display. But then looked at in isolation Win32's GDI32 drawing API has everything it needs to drive a high resolution display.
  
  The problem in Windows was that GDI32 did not sit in isolation. Quartz 2D doesn't seem to either, according to any of Apple's architecture diagrams and that's what worries me.
  
  One of the specific problem in Windows was that a given window was formed by composing lots of individual windows together. It was this composition step that was an issue, because the compositor was not resolution independent.
  
  There a number of other problems, most problematic of which is that applications that didn't test at different resolutions would work just fine at their default resolution, but you'd get a bunch of off-by-one errors when changing resolution, even though they were theoretically doing the right thing. You can actually see exactly this kind of effect in the PDF I produced on OS X earlier - the middle of the button isn't quite the same height as the rest of the button. It looks OK at some sizes, but at others, it looks clearly wrong. The net result is that even when you do get things to scale, everything suddenly ends up looking really rough round the edges. This is a real problem - it means that even if you're hypothetically resolution-independent, things probably won't look right unless you've tested at multiple resolutions. Given that OS X does not, as far as I know, provide a means of changing the notional pixel resolution of the screen, presumably nobody is testing for this today. So the point at which we find out whether everything works in practice is if/when such a feature eventually gets added.
  
  If there's some resolution independence testing tool I've not come across, then I'll happily recant on this point too. Is there some test harness I can run my apps in to see how they'll get rendered on a high DPI display? I'm not happy trusting to faith that things will just work. (In my experience, this isn't true, even when you've tried to do everything in the right way. I've seen too much code end up drawing almost but not quite the right thing at scale factors other than the default.)
  
  Apparently lots of people don't even know that it's possible to change the notional pixel resolution settings on current versions of Windows, because nobody tests. You can do it, but so much software breaks it's barely worth it.
  
  
  But back to composition...
  
  If I understand you correctly, you're saying that each window in OS X is really one big Quartz 2D surface. If that really is the case, then the only remaining problem (other than the lack of a test harness to view your windows at non-default scales) is a cultural one: Apple set a lead by using bitmaps for all of their widgets, and most application developers have followed suit. But if a window really is one big 2D surface, that's a problem that has a technical solution, so it merely needs Apple to provide some leadership here.
  
  What I'm still having a hard time grasping is your explanation of how this 'one big Quartz 2D surface per window' thing squares with integrating other imagery sources. You say that QuickTime can be instructed to render to the appropriate resolution, but I'm still not quite clear on how the results get composited. Somehow the rasters generated by the QuickTime engine have to appear on the same screen as the rasters generated by the Quartz 2D engine. What's responsible for doing this? According to Apple's documentation, it's the compositor. Are you saying it's not?
  
  If it is the compositor, how is the QuickTime engine (or the OpenGL engine) supposed to find out about what scaling is supposed to be applied? Because the transformations are all part of Quartz 2D, they're not something the compositor understands, so there must presumably be some out-of-band mechanism to keep the scaling of the various different drawing engines you are using in sync. How is that done? Is this the responsibilty of applications? Also, the compositor appears to work in whole pixels. (Run Expose in slow mode - Shift-f9 or Shift-f10. Watch how it is unable to deal with windows which, according to their current scaling, should really have edges at sub-pixel locations. Put a window near the top left, and watch how its top position steps up one pixel at a time rather than moving smoothly like the rest of the screen.) So what happens when your transform model says that QuickTime should be rendering into something that's 24.3 pixels wide, and located at 100.2,80.8? It's going to have to bump it to some whole number of pixels location and size. Or can the QuickTime renderer deal with this subpixel stuff too?
  
  Also, out of interest, can the QuickTime renderer deal with other transformations like rotation and shearing? (And if not, what happens if you're using these in Quartz 2D in the same UI that you're using QuickTime in?)
  
  
  
  What my current thinking boils down to is this: I see a system with a combination of elements I have known to cause problems with scalability in the past, and this is why I suspect there will be problems, particularly as you can't test a whole application for resolution independence today. I cannot prove to you that there is definitely a problem. Indeed it is possible, if windows really are one great big Quartz 2D surface, that high-DPI really will just work. However, the fact that you can't test for high-DPI correctness today makes me suspect that a lot of applications will look a bit wonky in practice - I've found that in general, if you don't test there's a high probability of failure. I still maintain that vector retention is a better solution to the problem because it has better performance characteristics. (Remember, doubling the resolution will quadruple the number of pixels that need to be pushed. In Quartz 2D's case, those pixels need to be pushed across the bus from main memory into the GPU.)
  
  
  "You forgot a third one: hand-painted bitmaps used for the display but rendered through Quartz 2D. Again, how would those benefit from a retained representation?"
  
  I already brought this topic up actually. Earlier in the conversation I complained that "There seems to be a lack of leadership here from Apple - all of their graphical widgets appear to be bitmaps, not vector images." You've brought up the very issue I was referring to.
  
  Obviously hand-painted UI bitmaps are anathema to device independence. This is why Microsoft are pushing a very clear message that you should no longer do this, and it's why they are moving all their own widgets over to a vector form.
  
  It's very clear what The Right Thing to do here is. Microsoft have made it very clear that high-DPI is considered an important feature, and that vector imagery is the way to go. (This was repeated many times over at the conference where Avalon was launched. Microsoft really want people to be aware of this.)
  
  This is not a technical issue of course. You can use vector imagery today in OS X. It's just a leadership issue. (The 128x128 pixel standard for icons is OK so long as you think displays will never go above their current resolutions. But 200dpi displays have been around for a while now - a 300dpi display is a resonable possibility, and a desirable one at that - after all, it's still possible to make out the individual pixels on a 200dpi display. At 300 dpi, your 128x128 pixel image is now less than half an inch across. This constrains your design - I happen to rather like the cartoon-like vastness of the images I get today when Alt-Tab switching in OS X, but I'm not going to be able to have those on a 300dpi display without loss of image quality.)
  
  
  
  "...the apps with the highest performance requirements are video editing and 3D, and that both of these don't use Quartz 2D [...] Anyway: if both of these do not use Quartz 2D, how would speeding up Quartz 2D help them? Answer: it wouldn't."
  
  Am I right in saying that you're making the following unstated argument: only the two most demanding application areas on the Mac get high performance display piplines, so it must therefore be pointless speeding up anything other than the two applications with the highest demands.
  
  (I'm trying to understand why you said what you said. The only way I've been able to make sense of it so far is if you are taking that argument as being implicit.)
  
  If I've understood your argument correctly, my response would be that the one reason you don't see any graphically demanding applications using Quartz 2D is that Quartz 2D's architecture makes it impossible to write graphically demanding applications.
  
  You can't point to the dearth of graphically intensive applications available that use Quartz 2D and use that as evidence that there is no requirement for better performance. Couldn't it be that Quartz 2D's architecture is stifling innovation in this area?
  
  
  "As you yourself have pointed out, both speed and quality requirements are different for dynamic and static media"
  
  Actually I don't think I did say that. What I said is that the applications that require high quality don't use the Quartz 2D pipeline. So I don't regard what you said there are an accurate characterization of what I said.
  
  The point I was making was simply that the Quartz 2D pipeline is no good for high performance work. This is very different from saying that there is no need for a high performance 2D pipeline. I was just saying that Quartz doesn't have a high performance 2D pipeline.
  
  
  
  By the way, you've not replied to my comments on the relative abilities of Quartz 2D and GDI+. I asked if you could name anything Quartz 2D could do that GDI+ could not. (You claimed that GDI+ was not up to the level of Quartz, and I was asking you to substantiate that claim.) Did you forget? Or are you changing your position on this point?
• macos x already works like this
  2004-05-23 22:06:41  glenlow [View]
  
  
  "Can you show me an application that illustrates zooming in on vector imagery in OS X that does use Quartz then? I'd like to be able to see a proper side by side comparison. What about Omni Graffle? Is that using Quartz 2D? That only seems to manage about 4 redraws a second if I hammer on the mouse button using the zoom tool. It's not keeping up with the mouse clicks for a relatively simple drawing. (The terrible horse drawing I posted earlier.) This suggests that it isn't going to be good enough for a smooth (as in full field rate video playback smooth) zooming."
  
  Take a look at my Mac OS X port of Graphviz: http://www.pixelglow.com/graphviz/, a released and production-used app. In particular it uses pure PDF (via Quartz 2D) to draw the graphs, and specifically disables cached bitmaps. As a result rendering is smooth and fast enough to work with a dynamic, live zoom (a slider control).
  
  Try opening graphs with a lot of nodes e.g. awilliams.dot. You can fiddle around with the default colors to get alpha transparency happening and in 10.3 a drop shadow delineates the graph boundary, all within the Quartz 2D/Cocoa API.
  
  The graph PDF is a retained vector representation, of course. As you can see, the Quartz 2D pipeline is pretty good for high performance work!
  
  My main irritation with Quartz PDF is that it's hard to do selective edits of a PDF, since the Quartz model is more a "lay down paint" model like PostScript rather than a full object model.
  
  Cheers,
  Glen Low, Pixelglow Software
  www.pixelglow.com
• macos x already works like this
  2004-03-22 15:32:48  mweiher [View]
  
  
  
  

  1. Application that provides smooth zoom

  
  
  

  Just modify your NSImageView a tiny little bit. Add a class BetterNSImageView with an instance variable id pdfImageRep.

  
  
  

  To this add the following two methods:

  
  

  
  
  -(void)drawRect:(NSRect)r
  
  {
  
          if ( pdfImageRep ) {
  
                  [pdfImageRep drawInRect:r];
  
          } else {
  
                  [super drawRect:r];
  
          }
  
  }
  
  
  
  -(void)setImage:(NSImage*)anImage
  
  {
  
          [anImage setDataRetained:YES];
  
          pdfImageRep=[[[anImage representations]
  
              lastObject] retain];
  
          [super setImage:anImage];
  
  }
  
  

  
  
  

  (This code will leak the image-rep, but that's OK for us here)

  
  
  

  The clou here is drawing the PDF directly, instead of recaching an NSImage each time around. That makes things significantly faster. I haven't put in the code that takes care of keeping the aspect ratio the same, this doesn't affect the speed and is left as an exercise for the reader.

  
  
  

  This redraws interactively on my dual 1 GHz G4 and my 867 MHz 12" PowerBook, though it is a bit more sluggish on the PowerBook. Or, to put numbers on that, add the following trivial "benchmark" code:

  
  
  

  
  
  -(void)doScaleBench:sender
  
  {
  
  	int i;
  
  	NSWindow* win=[self window];
  
  	NSRect r=[win frame];
  
  	
  
  	NSLog(@"start %@",[NSDate date]);
  
  	for (i=0;i<10 ;i++) {
  
  		r.size.width++;
  
  		r.size.height++;
  
  		[win setFrame:r display:YES];
  
  	}
  
  	NSLog(@"stop %@",[NSDate date]);
  
  }
  
  

  
  
  

  Hook that up to a menu item in Interface Builder.

  
  
  

  On my 867MHz 12" PowerBook, that yields between 7.41 redraws/s for a complex PDF with a full page of text and 17.2 redraws a second for a simple PDF with a couple of shapes and a small amount of text. A full page of text being rescaled is very rough, because text is expensive to render and you aren't getting much use out of the text cache.

  
  
  

  On the 1 GHz G4, we get 12.5 and 31 redraws / second, respectively. A current model G5 should be more than twice as fast, and I wonder what will be available by the time Longhorn/Avalon ships. But it's always surprised me how much faster Safari is on my 12" PowerBook than the 1.4 GHz Dell I have at work. Apart from looking incomparably better...

  
  
  
  

  2. "wether mac os x has a [retained vector] mechanism like this"

  
  
  

  *double cough* This is from the start of my first post to this thread:

  
  
  

  "The fact is that Mac OS X already *does* work mostly like this, except for retained vectors"

  
  
  

  To which you replied:

  
  
  

  "But my point is that the retained vectors are crucial."

  
  
  

  'nuff said.

  
  
  

  3. Quartz compositor hypotheses

  
  
  

  Just complete bollocks. Completely unrelated. Apart from being untrue, this is still bitmaps being drawn with Quartz 2D, not stuff that is turning into bitmaps as a result of the Quartz compositor, which has nothing to do with that at all.

  
  
  

  4. OpenGL + QuickTime + Quartz

  
  
  

  5. Diffuse worries

  
  
  

  OK, so you had bad experiences with Windows drawing APIs that just didn't work as advertised. Yes, that is also what I heard. Especially the transition from the initial GDI to the one that supported a "Postscript-like" imaging model, with arbitrary affine transformations. I remember thinking to myself "hey, this does all I need", but then hearing that, in fact, it doesn't actually work. However, I never tried it myself, but you seem to corroborate this.

  
  
  

  This is also where I get confused as to which Windows API is which. I remember that the original GDI did not support arbitrary (affine) transformations, or bezier-based paths. Did it support path-based clipping? The API that followed was very closely modelled after the Postscript imaging model, but that was the one that didn't really work as advertised, at least initially. Was that GDI+? I seem to be getting conflicting messages on that. You seem to say that GDI+ came with XP, but that would mean there must have been an intermediate API. Was there some renaming in the meantime?

  
  
  

  Anyway, whatever bad experience you had with Windows APIS, the good news is: Quartz Just Works(tm), as did DPS. Your worries, as applicable as they are in the Windows world, simply do not apply here. I have lots of ideas why this is the case, but these aren't really that important. What is important is that it does just work.

  
  
  

  [Possible reasons: well-defined drawing model, with precisely specified rendering semantics; history of implementations that have always been and continue to be device-independent stretching back more than two decades; surrounding APIs that have traditionally always worked in conjunction with a fully device-independent imaging model and count on that working correctly; developers that have worked with a device-indepndent imaging model for more than a decade etc.]

  
  
  

  6. Concrete compositing worries

  
  
  

  Anyway, you do give one concrete reason why there were problems with Windows, which is that windows are composed of lots of smaller windows. This isn't the case with normal Quartz windows. It is only true (to a much lesser degree) when the Quartz compositor is used to combine other media-types.

  
  
  

  However, virtually all the concrete worries you have expressed about (sub-)pixel boundaries, arbitrary scaling and so forth already apply today in exactly the same way! So either everything is as broken as you think it will be in the future today, or it won't be broken in the future either.

  
  
  

  [Exposé as 'proof' of compositor limitations: how many more #$%!@# lame examples are you going to come up with?! Exposé is intended to give you a rough overview over your windows, not provide precise rendering. Also, if anything it is an example of limitations of GPU-based drawing...]

  
  
  

  7. One big Quartz 2D surface

  
  
  

  For most windows, that is exactly what it is. The only exceptions are those that explicitly include dynamic media such as QuickTime movies and OpenGL-rendered 3D graphics

  .
  
  

  And yes, of course it is the compositor that is placing those QuickTime streams inside Quartz windows. What else? I really understand where you're getting all this from. You seem to have a profound misunderstanding of how all this works somewhere, but I am at a bit of a loss where it is.

  
  
  
  

  8. "At 300 dpi, your 128x128 pixel image is now less than half an inch across."

  
  
  

  This makes me wonder wether you understand what device-independent graphics means at all. Probably not. The same image will be precisely the same size as it was before. It will also look (almost) exactly the same. It just won't improve as much as a vector drawing will. However, most of the time those 128 x 128 icons are drawn much smaller than 1:1, and at those sizes a higer DPI display will display those icons with much finer details than possible today.

  
  
  

  Incidentally, that applies to all the other bitmaps in the UI, for example the traffic-light close/minimize buttons. They will render just fine even at the higher resolution, they just won't benefit much from it. That is what device-independent rendering is all about. Of course, it will be trivial for Apple to provide higher-resolution bitmaps for those higher resolution displays, or vectorized versions if that is appropriate/desirable.

  
  
  
  

  9. Static vs. dynamic graphics pipelines (and retained vectors)

  
  
  

  '"As you yourself have pointed out, both speed and quality requirements are different for dynamic and static media" Actually I don't think I did say that.'

  
  
  

  Er, yes you did. Earlier. On bitmap-stretching used by, for example, the genie effect:

  
  
  

  "Quartz gets away with this for high-speed animations like minimization because they're over before you have a chance to see the imperfections. But it would not stand up to close sustained scrutiny. And a crummy image would completely defeat the purpose of a high-dpi display!"

  
  
  

  So, at high speeds, you can get a way with imperfections. At low speeds, or a static display, you can't.

  
  
  

  So once again, for 3D and video work, you have the fast 3D and video pipelines. For mostly static displays, you have the very high quality Quartz 2D pipeline (and you can mix in the other pipelines when necessary). Quartz 2D is plenty fast for 2D non-media, non-movie work, and offers precision/quality that other APIs can't match.

  
  
  

  Also, you still haven't explained how 2D retained vectors would improve movie playback or OpenGL based 3D work. Are we going to vectorize movies on the fly? Is OpenGL going to render to a 2D vector representation? I don't think so.

  
  
  

  10. "retained vectors" ... "may not the only possible solution" for "High DPI"

  
  
  

  Good, we are making progress, then. However, it turns out that wether vectors are retained or not is completely irrelevant to the High DPI "problem".

  
  
  

  Unless you are going to make the absolutely absurd claim that QuickTime movies are going to vectorized on the fly and OpenGL will render down to 2D vectors instead of bitmaps, you are still going to have to composite at least some bitmaps together when you join up these different pipelines, at some point, wether you have a retained vector representation or not. It only happens at a different point in the pipeline that is all, but the actual issues of compositing the bitmaps together remains exactly the same.

  
  
  

  The other issue is bitmaps shoved into the graphics pipeline at the application end. Again, this has nothing to do with wether you have the ability to retain (vector) representations inside your graphics subsystem (or on the graphics card for that matter) at all. It is *solely* a matter of the applications providing vector or bitmap data. So once again, the API makes no difference whatsoever

  .
  
  

• macos x already works like this
  2004-03-19 20:59:37  rosyna [View]
  
  
  I cannot seem to respond to Ian's reply that spawned this reply (server error). It might have been too long since the last reply was made on this thread so no one may ever see this post.
  
  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. For the Close, Minimize, Zoom buttons, toolbar buttons (tic-tac), background patterns, and menu backgrounds bitmaps are used. This doesn't mean that Quartz 2d isn't scalable it means that OS X doesn't use PDF operations for widgets. There are many reasons for it. 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. 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.
  
  Let's look at two different windows. We have this one from longhorn. Look at the metal lookalike. One very smooth image with no imperfections "patterns". Now let us look at this clock thing here. Notice the wallpaper. Not scalable. It is a bitmap. Look at the image on the clock window. Also not scalable. Now, the Finder. You cannot tell too much from the screenshot but that metal window has imperfections. It *looks* like metal. It is not flat. It cannot be represented as a vector image without 1000s (or more) of paths. No way a GPU is ever going to handle it. So basically as the amount of vectorness goes up, the amount of uniqueness decreases while the amount of "flatness" increases. This is how OS X would look if it was all vector.
  
  And for the TextEdit example. You seriously expect a GPU to handle typographic layout? You want them to look at the kerning of the fonts, ligatures, baseline spacing, direction of type, and word wrap? That's what you seem to be saying. It is Not and operation for video cards to do. Ever.
• 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?