[Millennium]

Originally posted by Kate:
Isn't this the direct result of Apples Quartz policy? I mean they abandon GPU based drawing first and make much of the GPU and graphics hardware a heap of useless silicon for Mac OS X...

I'm going to assume that by "GPU-based drawing" you mean "bitmap-based drawing". That's all that was abandoned by Apple, and even then not entirely. QuickDraw and QuickTime still very much depend on it. QuickDraw is falling out of usage, but QuickTime is most certainly not.

Even with this switch to a more 3-D emphasis, the 2-D GPUs still have their place, because they can be used with textures that get mapped onto 3-D objects.

What if the graphics were based on more common tech, let's say e.g. OpenGL instead of Quartz.

From everything I've seen, it looks like there's OpenGL under there; Quartz is simply moving more and more towards being implemented on top of OpenGL. This grants the best of all possible worlds; the acceleration of OpenGL systems, but

But OpenGL, at least in its current incarnation, is not perfect. It lacks some features which are, frankly, critical for some applications. OpenGL 2.0 should fix this, but until that is released, graphics card makers are left to implement their own proprietary solutions for things such as pixel shaders. By providing a layer of abstraction over these via Quartz, Apple is making a tremendous leap towards portability, and when the standards for pixel shaders come they can simply be plugged in as another driver. Not only this, but this added layer of abstraction cannot help but bring pixel shaders -an arcane technology if ever there was one- out into the limelight.

Sure some features would not be here, but the problem with lack of hardware rendering would not either. And cross platform questions of that type would not be there.

There will be cross-platform questions anyway, because no one else really has a decent 2-D API on top of OpenGL yet (for good or for ill Avalon isn't here yet, so it can't count). Apple is basically the first one; there are no standards to follow.

As it is, CoreImage has hardware acceleration. For older graphics cards without any pixel-shading technology at all, Apple is providing an emulator, which is the best that can possibly be hoped for (and a major change from their previous policy of simply dropping anything that didn't have the requisite technology).

So was/is Quartz worth all this? From the point of a GUI driven OS, Quartz seems massive overkill.

And if Quartz existed only for the sake of Mac OS X itself, you would be right. But it doesn't exist in a vacuum; there are plenty of applications which can and do make very real use of it. Quartz exists to provide these appplications with a leg to stand on, so to speak.

Semi transparent menus were there in OS9 with Quickdraw.

Really? Where? I never once saw such a menu.

So why Quartz and where does Quartz aim?

The future.

[Millennium]

Originally posted by weezie:
How will core image deal with large image files? Will its effects be scalable?

By what definition of "scalable"? Do you mean scalable as in "works well even with large images", or scalable as in "works with images that have been resized"?

Imagine working on a large color spread. It could easily be 18x12'' @300 ppi or much larger. Will you need to have the image be displayed at 100% to have good control over the filters?

My guess is that CoreImage will filter the image at 100%, then scale it down to fit the display.

This has obvious problems, such as, there is no display that exists that could show the whole image at 100% -- even the new 30'' is not up to that task. Or will the filter parameters adjust for whatever magnification you may be displaying the image at?

CoreImage would need a way of knowing what magnification you were using. If it were to operate on the display context -that is, what's actually being shown onscreen, rather than the image itself- then things might be different. I don't know if it can do that, though.

Also, an image like this is way over 4 million pixels, so will this be a problem for GPUs? (I'm thinking not because we are talking about a static image compared to an ever updating GUI, but I thought I'd ask)

An image that large will take time to process in hardware, just as in software. Hardware can do it faster, of course -that's always true for hardware vs. software stuff- but it will still take some time. That's just the nature of image processing. Whether the time it takes will be noticeable on an image of that size remains to be seen.

[Kate]

Originally posted by Millennium:
Really? Where? I never once saw such a menu.

http://www.kaleidoscope.net/greg/PowerWindows.html

Provided transparent menus as well as transparent windows while beeing dragged, fading menus and it seems to work still under the Classic environment.
Not a part of Mac OS 9 itself, but it shows that gadgets were possible even then.

Originally posted by Millennium:
The future.

I hope so too.

Any sign of improvements to the text rendering engine?

[JLL]

Originally posted by Kate:
http://www.kaleidoscope.net/greg/PowerWindows.html

Provided transparent menus as well as transparent windows while beeing dragged, fading menus and it seems to work still under the Classic environment.
Not a part of Mac OS 9 itself, but it shows that gadgets were possible even then.

Yes, but it required a lot more coding.

Originally posted by Kate:
Any sign of improvements to the text rendering engine?

Yes, Quartz 2D can now be accelerated, but it's turned of by default in the preview.

[entrox]

Originally posted by Millennium:
But OpenGL, at least in its current incarnation, is not perfect. It lacks some features which are, frankly, critical for some applications. OpenGL 2.0 should fix this, but until that is released, graphics card makers are left to implement their own proprietary solutions for things such as pixel shaders. By providing a layer of abstraction over these via Quartz, Apple is making a tremendous leap towards portability, and when the standards for pixel shaders come they can simply be plugged in as another driver. Not only this, but this added layer of abstraction cannot help but bring pixel shaders -an arcane technology if ever there was one- out into the limelight.

Your post is pretty good, but this made me go 'huh?'. Vendor independent fragment programmability has been in OpenGL since version 1.3 in the form of the ARB_fragment_program extension. The newer stuff, which is available in the OpenGL 2.0 core, can be accessed through the ARB_fragment_shader extension in OpenGL 1.X, so I don't see where you're getting at. But perhaps I'm misunderstanding you.

There is one more important thing than fragment programmability: OpenGL is not specified to be pixel exact. That means different hardware is allowed to deviate in how they rasterize things. While this is no big problem in medical imaging, flow simulation or games, it can be disastrous in applications like Photoshop, where the same pixels should be set no matter what your hardware is. The same rules apply to fragment programs, since they need to be invariant with the fixed-function pipeline.

I'm curious as to how they've got around this.

[arekkusu]

extrox is exactly right. OpenGL is, by definition, not pixel-exact. You don't notice this very much playing 3D games because everything is moving around all the time. But if you stop and try to draw the letter "A" with vectors you'll find that it comes out slightly differently depending which video card you use. Very very fundamental things like

1) draw a point
2) draw a line
3) draw a triangle
4) fill with color gradient
5) fill with texture

are NOT the same across different cards. Sometimes the differences are subtle and sometimes they are wildly different. I've taken a bunch of screenshots to show some of the differences: http://homepage.mac.com/arekkusu/bug...ance/HWAA.html

Some of these problems can be reduced by clever tricks, or moving to floating point fragment shaders. But it only _reduces_ the problem by increasing the precision of the calculation-- there will still be a few bits of difference in the result. Whether that difference is visible to the user really depends on the application.

[moki]

Originally posted by weezie:
How will core image deal with large image files? Will its effects be scalable? Imagine working on a large color spread. It could easily be 18x12'' @300 ppi or much larger. Will you need to have the image be displayed at 100% to have good control over the filters? This has obvious problems, such as, there is no display that exists that could show the whole image at 100% -- even the new 30'' is not up to that task. Or will the filter parameters adjust for whatever magnification you may be displaying the image at?

CoreImage is designed to work with images of *infinite* size. I think that solves the problem right there. If the image is too large to fit on the video card, CoreImage automatically breaks it up into strips, processes it, and puts the strips back together as the end result. Slick.

[moki]

Originally posted by Kate:
rovided transparent menus as well as transparent windows while beeing dragged, fading menus and it seems to work still under the Classic environment.
Not a part of Mac OS 9 itself, but it shows that gadgets were possible even then.

Yes, but that gadget was a hack. Quartz is an extremely good and forward-thinking imaging model. Everything you're seeing today would have been impossible without an imaging model like Quartz.

There are many key differences between old imaging models like QuickDraw and Quartz. It's like someone trying to state that they can soup up their old VW bug to compete in a formula 1 race. Maybe they can bolt a couple of things to the engine block, but it just isn't in the same league.

Apple has many documents available online at: http://developer.apple.com/ that give excellent overviews of Quartz, if you're interested. It was absolutely the right choice of imaging models to go with.

[Kate]

Originally posted by moki:
....It's like someone trying to state that they can soup up their old VW bug to compete in a formula 1 race...

I know what you mean, but in the field of the 2D GUI nearly everything is sub formula 1 standard, so to speak, in fact it shows even less performance here and there than a VW bug beetle in F1 would.

Apples dev docs discribe it like this in the Quartz Extreme section

"Hardware-accelerated graphics:

Responsive user interface"

Exactly. But Quartz seems to be less extreme and hardware accelerated than Quickdraw in some basic cases. Well there is the DirectDisplay API, but that's not what you want to use.

I hope at least that CoreImage will be what is needed to really make the experience "responsive".

[Millennium]

Originally posted by Kate:
Exactly. But Quartz seems to be less extreme and hardware accelerated than Quickdraw in some basic cases.

What cases are these?

[moki]

Originally posted by Kate:
Exactly. But Quartz seems to be less extreme and hardware accelerated than Quickdraw in some basic cases.

There is nothing -- no part of QuickDraw -- that on a technical level is better than Quartz. As for the hardware acceleration, that is true, but it will be changing with Q2DE. Video cards simply were not capable enough until recently.