So, Kate, you think that having a central compositor and window server is a bad idea to begin with? Not happy that they created an environment that handles screen drawing and RIPping in the exact same way, independently of device characteristics? Bad idea to have the software do all coordination among graphics APIs, file types on screen, anti-aliasing, buffering, and image manipulation on the fly? That true WYSIWYG isn't all it's cracked up to be?
<hr></blockquote>
No, those strategic goals are fine and worth making great efforts.
But I think they want too much too soon and overburden the feasible IMHO.
BTW, there are and there were other OSes who use similar technology less advanced but more humble and very very efficient. I cannot see any technical reason why the existence of modern drawing APIs or a modern Window Manager forces you to give up 90% of the available 2D performance. And I really see no reason to PDF-render everything as long as screen resolution is smaller than 300dpi and even with a resolution like this I see no benefit from rendering everything then, not even cosmetic ones.
Oh, and BTW kerning is something you need with fonts, but font handling in Quartz seems not to allow that yet, so it is already lacking, no?. PS or PDF rendering of text on screen is fine, but you see what happens when that approach includes everything: Fonts are blurred and unreadable as long as they are below 16 pt, graphics is generally blurred as long as it comes not in ridiculously big sizes. And that is with a 96 dpi TFT, not the usual 72 dpi CRT. Really, the tradeoffs are not worth the results here.
The concept of infinite numbers of possibly transparent PDF rendered layers is a bit too much. Why not limit those API functions in the current incarnation and extend and improve the functions and lift limits when technology gets on par? Leave room for a supercharger in the engine compartment and put in what makes the thing move now. Yes there are tradeoffs, you have to design parts that can work still when the supercharger gets "in", so to speak, but that does not mean the whole machine will be limited to first gear for the time being.
[quote]To make my point clear: the hardware is the problem here, not the software. If you handicap the software technology you plan to develop over the next 10-15 years because of the hardware you plan to use for the 5, then your strategy is fundamentally wrong. <hr></blockquote>
This is to overburden the design. I think none knows what we will see in the next ten years in the field of computing. Preparing for the obvious is necessary but to bloat everything because you expect the unknown is silly.
And QE still does nothing in the field of 2D Quartz acceleration. If a hardware "solution" for this gets born somewhere, possibly QE needs a major redesign. So right now I expect further construction and redesign where Quartz should provide the opposite.
And QE still does nothing in the field of 2D Quartz acceleration. <hr></blockquote>
2D acceleration being?
scrolling? - This is already being accelerated by the video card.
what else 2D do you want accelerated?
(I guess the generation of paths and rectangles?)
personally, I'm doing a lot of cool programming stuff that I couldn't do before (due to the compositor). The speed of my programs now is passable, with the QE it should be very nice.
QE=Hardware thrown at Quartz Compositor.So no acceleration for Quartz 2D. And Quartz 2D is virtually everything besides compositing, OGL and 3D.
P.S. Rumors are telling that there ARE efforts being made with regard to 2D acceleration in Quartz under 10.2 . If this turns out to have same real impact I'd gladly revise my judgement the day I get 10.2 .
P.P.S. I'm running 10.1.4 full time on two machines. I'm not bashing anyone here for fun.
So no acceleration for Quartz 2D. <hr></blockquote>
Care to answer the question this time? You don't need to hide your ignorance by trying to illustrate the various components of Quartz. I have a bit of experience there.
Aqain what are you talking about? There already is some 2D accelleration in the windowserver (scrolling for example). What else are you looking for? Hardware generation of AA bezier paths? We have that already, its called the cpu... I know... I know....
But I think they want too much too soon and overburden the feasible IMHO.
But I think it's already been made feasible, just not a speed demon on all hardware.
BTW, there are and there were other OSes who use similar technology less advanced but more humble and very very efficient. I cannot see any technical reason why the existence of modern drawing APIs or a modern Window Manager forces you to give up 90% of the available 2D performance.
I think you're right about the fact that it's probably not as efficient as it could be even with QE, but is anyone doing what this is exactly? That is, is there a lot of precedence to this to learn from? Even Display Postscript doesn't have all these features and is relatively slow. But I do think you're exageration of the performance problems (which is a messy subject anyway thanks to bad Carbon apps like the Finder) helps to make it sound less successful than it already is.
And I really see no reason to PDF-render everything as long as screen resolution is smaller than 300dpi and even with a resolution like this I see no benefit from rendering everything then, not even cosmetic ones.
Again, just WYSIWG. I think it needs improvement especially on small text rendering (apparently Quartz is capable of doing sub-pixel rendering according to Apple docs --let's hope!) but I would say that the rationale is obvious.
Oh, and BTW kerning is something you need with fonts, but font handling in Quartz seems not to allow that yet, so it is already lacking, no?
Uh, kerning works just fine for me, unless you mean when anti-aliasing is turned off, then yes it's all screwed up. I assume kerning takes into account the anti-aliasing, so the metrics change when it's eliminated and I guess it doesn't know what to do without the anti-alising. But kerning is fine by default, even better since it understands ligatures too. Again, I think you're exaggerating what is a problem with small serif fonts (and really small san serif ones). Take a look at a pdf in OS 9. I always have to blow those things up to 125% to read the 8pt type, so you can see why OS X inherits this problem. But I think it's a matter of fixing/updating the spec, not a false start.
The concept of infinite numbers of possibly transparent PDF rendered layers is a bit too much. Why not limit those API functions in the current incarnation and extend and improve the functions and lift limits when technology gets on par? Bah! We both know the answer to that is because if you start that way, it gets left that way. Look at Mac OS 9 for plenty of those mistakes.
I think none knows what we will see in the next ten years in the field of computing.
But Apple, like they did with the Classic OS, has banked big time on this foundation. You don't invest in this foundation for the next 3 years simply because it's economically impossible to keep jumping ships that often. tHat's why you design maximum flexibility and upside to your technology, knowing that you don't know where the market will go down the road. To me, this is what Quartz does. It's possibly the most flexible API and engine around.
And QE still does nothing in the field of 2D Quartz acceleration. If a hardware "solution" for this gets born somewhere, possibly QE needs a major redesign. So right now I expect further construction and redesign where Quartz should provide the opposite.
I don't understand what you mean. Yes, QE is really offloading compositing work to the relatively idle GPU, which has a potential side effect of speeding things up a little or a lot(leaving more open RAM, less disk swapping, faster pipeline, direct screen draw, less data juggling by the CPU, etc.). If menu drops are your only problem with OS X's display, you'll see minor improvements at least. If you get the spinning MO disc a lot, that too will occur less often. Remember that QE is a kind of port or emulation of plain ol' Quartz. They always have the source that can render on the CPU, and the srouce to port from again if needed.
I just don't see how QE is a bad thing, nor Quartz. The technology and ideas are sound, if they do need further refinement. That pretty much sums up my viewpoint. It's not a question of validity.
I don't understand the part about "I expect futher resdesign and Quartz to provide the opposite."
*****
So can anyone answer how much of Quartz's problem areas are based in the 2D API and how much in the compositor? In other words, where is the weakest link?
I didn't mean to start a troll war or a flame fest, my fault. I guess, as far as opinions go, we'll just have to agree to disagree. My apologies. (it was a long day...... I was working on PCs. )
Eh, we've all been there. It would be nice to delve into the details of Quartz 2D, any of its inefficiencies as well as the compositing portion. I was perusing the Quartz 2D overview but it looks like gibberish to me beyond the conceptual explanations. I can't find much of anything regarding the Quartz compositor much beyond its mention in the Quartz overviews. The nitty-gritty about the compositor is likely kept close to Apple's vest.
<strong>Eh, we've all been there. It would be nice to delve into the details of Quartz 2D, any of its inefficiencies as well as the compositing portion. I was perusing the Quartz 2D overview but it looks like gibberish to me beyond the conceptual explanations...</strong><hr></blockquote>
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?</strong><hr></blockquote>
Beans!! Or in lue of that how about some good documentation that we lay users can use to better understand Quartz. Or if you are up on Quartz you could wax technical and we will stop you (lots) to clarify.
We have that already, its called the cpu... I know... I know....</strong><hr></blockquote>
Huh? You answered your own question there, it's the cpu not the gpu, use of the gpu is called hardware acceleration of graphics functions. If you have a bit of experience you may know that Quartz 2D uses the BitBlockTransfer functions of GPU hardware and that's it what allows for a bit of jumpy slow scrolling (because the compositor and renderer kicks in?) and life window dragging . If you list calls of Quartz 2D to hardware functions of a graphics card you find only three or four function calls used and none of the fifty other available functions. You're right, hardly any of these can help drawing Bezier type curves.
just wanted to let you know, that this thread is very informativ (well exept the flaming of some bored people) for people like me - who don't have that deep knowlege of this.
go on!
..and try to be polite - we're not in a peecee-forum here.
The velocity engine actually becomes more effecient with QE because now the CPU and VE can concentrate on getting work done instead of using clock cycles to display everything on screen.
Jaguar itself is a win-win for everyone, it'll just be more effecient for those with supported hardware.
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?</strong><hr></blockquote>
Shouldn't that be obvious? Explain the full detail, that's what causes the most questions. How is life window dragging possible if you use a transparent window?
If I have a pixel image to display it is squeezed through the renderer, the compositor and then dropped into vram, is it? Is there a difference between a pixel image and let's say a font? If so, what are the differences and why?
Aqain what are you talking about? There already is some 2D accelleration in the windowserver (scrolling for example). What else are you looking for? Hardware generation of AA bezier paths? We have that already, its called the cpu... I know... I know....</strong><hr></blockquote>
This is incorrect. Hardware accelerated scrolling is one of the features going to be introduced in Jaguar. This is the principle reason you hear people raving about how much faster scrolling is in the Jaguar demo - it's finally using the hardware. Of course, most of them misattribute it to the wonders of QE.
When you scroll a window now, it redraws the entire scroll region rather than using the card to scroll the region and then paint only new pixels. This is patently obvious if you look at it with Quartz Debug enabled, and the reason why the scrolling in OS X is so chunky right now - the only way to get decent speed is to scroll in multiple line jumps.
Comments
So, Kate, you think that having a central compositor and window server is a bad idea to begin with? Not happy that they created an environment that handles screen drawing and RIPping in the exact same way, independently of device characteristics? Bad idea to have the software do all coordination among graphics APIs, file types on screen, anti-aliasing, buffering, and image manipulation on the fly? That true WYSIWYG isn't all it's cracked up to be?
<hr></blockquote>
No, those strategic goals are fine and worth making great efforts.
But I think they want too much too soon and overburden the feasible IMHO.
BTW, there are and there were other OSes who use similar technology less advanced but more humble and very very efficient. I cannot see any technical reason why the existence of modern drawing APIs or a modern Window Manager forces you to give up 90% of the available 2D performance. And I really see no reason to PDF-render everything as long as screen resolution is smaller than 300dpi and even with a resolution like this I see no benefit from rendering everything then, not even cosmetic ones.
Oh, and BTW kerning is something you need with fonts, but font handling in Quartz seems not to allow that yet, so it is already lacking, no?. PS or PDF rendering of text on screen is fine, but you see what happens when that approach includes everything: Fonts are blurred and unreadable as long as they are below 16 pt, graphics is generally blurred as long as it comes not in ridiculously big sizes. And that is with a 96 dpi TFT, not the usual 72 dpi CRT. Really, the tradeoffs are not worth the results here.
The concept of infinite numbers of possibly transparent PDF rendered layers is a bit too much. Why not limit those API functions in the current incarnation and extend and improve the functions and lift limits when technology gets on par? Leave room for a supercharger in the engine compartment and put in what makes the thing move now. Yes there are tradeoffs, you have to design parts that can work still when the supercharger gets "in", so to speak, but that does not mean the whole machine will be limited to first gear for the time being.
[quote]To make my point clear: the hardware is the problem here, not the software. If you handicap the software technology you plan to develop over the next 10-15 years because of the hardware you plan to use for the 5, then your strategy is fundamentally wrong. <hr></blockquote>
This is to overburden the design. I think none knows what we will see in the next ten years in the field of computing. Preparing for the obvious is necessary but to bloat everything because you expect the unknown is silly.
And QE still does nothing in the field of 2D Quartz acceleration. If a hardware "solution" for this gets born somewhere, possibly QE needs a major redesign. So right now I expect further construction and redesign where Quartz should provide the opposite.
[ 05-28-2002: Message edited by: Kate ]</p>
And QE still does nothing in the field of 2D Quartz acceleration. <hr></blockquote>
2D acceleration being?
scrolling? - This is already being accelerated by the video card.
what else 2D do you want accelerated?
(I guess the generation of paths and rectangles?)
personally, I'm doing a lot of cool programming stuff that I couldn't do before (due to the compositor). The speed of my programs now is passable, with the QE it should be very nice.
2D acceleration being?
<hr></blockquote>
Quartz=Quartz Compositor+ Quartz 2D
QE=Hardware thrown at Quartz Compositor.So no acceleration for Quartz 2D. And Quartz 2D is virtually everything besides compositing, OGL and 3D.
P.S. Rumors are telling that there ARE efforts being made with regard to 2D acceleration in Quartz under 10.2 . If this turns out to have same real impact I'd gladly revise my judgement the day I get 10.2 .
P.P.S. I'm running 10.1.4 full time on two machines. I'm not bashing anyone here for fun.
[ 05-28-2002: Message edited by: Kate ]</p>
So no acceleration for Quartz 2D. <hr></blockquote>
Care to answer the question this time? You don't need to hide your ignorance by trying to illustrate the various components of Quartz. I have a bit of experience there.
Aqain what are you talking about? There already is some 2D accelleration in the windowserver (scrolling for example). What else are you looking for? Hardware generation of AA bezier paths? We have that already, its called the cpu... I know... I know....
But I think it's already been made feasible, just not a speed demon on all hardware.
BTW, there are and there were other OSes who use similar technology less advanced but more humble and very very efficient. I cannot see any technical reason why the existence of modern drawing APIs or a modern Window Manager forces you to give up 90% of the available 2D performance.
I think you're right about the fact that it's probably not as efficient as it could be even with QE, but is anyone doing what this is exactly? That is, is there a lot of precedence to this to learn from? Even Display Postscript doesn't have all these features and is relatively slow. But I do think you're exageration of the performance problems (which is a messy subject anyway thanks to bad Carbon apps like the Finder) helps to make it sound less successful than it already is.
And I really see no reason to PDF-render everything as long as screen resolution is smaller than 300dpi and even with a resolution like this I see no benefit from rendering everything then, not even cosmetic ones.
Again, just WYSIWG. I think it needs improvement especially on small text rendering (apparently Quartz is capable of doing sub-pixel rendering according to Apple docs --let's hope!) but I would say that the rationale is obvious.
Oh, and BTW kerning is something you need with fonts, but font handling in Quartz seems not to allow that yet, so it is already lacking, no?
Uh, kerning works just fine for me, unless you mean when anti-aliasing is turned off, then yes it's all screwed up. I assume kerning takes into account the anti-aliasing, so the metrics change when it's eliminated and I guess it doesn't know what to do without the anti-alising. But kerning is fine by default, even better since it understands ligatures too. Again, I think you're exaggerating what is a problem with small serif fonts (and really small san serif ones). Take a look at a pdf in OS 9. I always have to blow those things up to 125% to read the 8pt type, so you can see why OS X inherits this problem. But I think it's a matter of fixing/updating the spec, not a false start.
The concept of infinite numbers of possibly transparent PDF rendered layers is a bit too much. Why not limit those API functions in the current incarnation and extend and improve the functions and lift limits when technology gets on par? Bah! We both know the answer to that is because if you start that way, it gets left that way. Look at Mac OS 9 for plenty of those mistakes.
I think none knows what we will see in the next ten years in the field of computing.
But Apple, like they did with the Classic OS, has banked big time on this foundation. You don't invest in this foundation for the next 3 years simply because it's economically impossible to keep jumping ships that often. tHat's why you design maximum flexibility and upside to your technology, knowing that you don't know where the market will go down the road. To me, this is what Quartz does. It's possibly the most flexible API and engine around.
And QE still does nothing in the field of 2D Quartz acceleration. If a hardware "solution" for this gets born somewhere, possibly QE needs a major redesign. So right now I expect further construction and redesign where Quartz should provide the opposite.
I don't understand what you mean. Yes, QE is really offloading compositing work to the relatively idle GPU, which has a potential side effect of speeding things up a little or a lot(leaving more open RAM, less disk swapping, faster pipeline, direct screen draw, less data juggling by the CPU, etc.). If menu drops are your only problem with OS X's display, you'll see minor improvements at least. If you get the spinning MO disc a lot, that too will occur less often. Remember that QE is a kind of port or emulation of plain ol' Quartz. They always have the source that can render on the CPU, and the srouce to port from again if needed.
I just don't see how QE is a bad thing, nor Quartz. The technology and ideas are sound, if they do need further refinement. That pretty much sums up my viewpoint. It's not a question of validity.
I don't understand the part about "I expect futher resdesign and Quartz to provide the opposite."
*****
So can anyone answer how much of Quartz's problem areas are based in the 2D API and how much in the compositor? In other words, where is the weakest link?
[ 05-28-2002: Message edited by: BuonRotto ]</p>
<strong>[b] In other words, where is the weakest link?
[ 05-28-2002: Message edited by: BuonRotto ]</strong><hr></blockquote>
I'll take a shot at that one:
The weakest link is the people who don't know squat about the technology and confuse slow apps for bloated OS foundations.
<strong>Eh, we've all been there. It would be nice to delve into the details of Quartz 2D, any of its inefficiencies as well as the compositing portion. I was perusing the Quartz 2D overview but it looks like gibberish to me beyond the conceptual explanations...</strong><hr></blockquote>
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?
<strong>
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?</strong><hr></blockquote>
Beans!! Or in lue of that how about some good documentation that we lay users can use to better understand Quartz. Or if you are up on Quartz you could wax technical and we will stop you (lots) to clarify.
You choose
<strong>
I have a bit of experience there.
Aqain what are you talking about?
We have that already, its called the cpu... I know... I know....</strong><hr></blockquote>
Huh? You answered your own question there, it's the cpu not the gpu, use of the gpu is called hardware acceleration of graphics functions. If you have a bit of experience you may know that Quartz 2D uses the BitBlockTransfer functions of GPU hardware and that's it what allows for a bit of jumpy slow scrolling (because the compositor and renderer kicks in?) and life window dragging . If you list calls of Quartz 2D to hardware functions of a graphics card you find only three or four function calls used and none of the fifty other available functions. You're right, hardly any of these can help drawing Bezier type curves.
go on!
..and try to be polite - we're not in a peecee-forum here.
is a move away from the G4/velocity engine
toward a newer chip
that runs without velocity engine.
Does the velocity engine become less important in QE??
cheers
Jaguar itself is a win-win for everyone, it'll just be more effecient for those with supported hardware.
<strong>
Well, what is it that everyone wants to know? I get the feeling most people here wouldn't understand if someone were to explain Quartz in full detail, yet there's this insatiable demand for someone to "spill the beans" on how things work on the inside. Just what is everyone looking for?</strong><hr></blockquote>
Shouldn't that be obvious? Explain the full detail, that's what causes the most questions. How is life window dragging possible if you use a transparent window?
If I have a pixel image to display it is squeezed through the renderer, the compositor and then dropped into vram, is it? Is there a difference between a pixel image and let's say a font? If so, what are the differences and why?
<strong>
Aqain what are you talking about? There already is some 2D accelleration in the windowserver (scrolling for example). What else are you looking for? Hardware generation of AA bezier paths? We have that already, its called the cpu... I know... I know....</strong><hr></blockquote>
This is incorrect. Hardware accelerated scrolling is one of the features going to be introduced in Jaguar. This is the principle reason you hear people raving about how much faster scrolling is in the Jaguar demo - it's finally using the hardware. Of course, most of them misattribute it to the wonders of QE.
When you scroll a window now, it redraws the entire scroll region rather than using the card to scroll the region and then paint only new pixels. This is patently obvious if you look at it with Quartz Debug enabled, and the reason why the scrolling in OS X is so chunky right now - the only way to get decent speed is to scroll in multiple line jumps.