i guess my point is, sure, it might be future-proofing, by the speed hit has caused more bad publicity than was worth it, in my humble opinion. generall double buffering code would be cut and pasteable anyhow. (or at least when learning directx, it's in the early chapters)
Ted</strong><hr></blockquote>
I've been hypothesizing so much... I'd like to test if double buffering really is the problem. I don't have much time now though.
But I agree. It is a tough call: Features or temporary sluggish performance??? IMHO, I'll take features as long as the slowdown is temporary. But then again, I am a very lazy programmer... Some graphic designers might think otherwise...
Let's hope Apple optimizes the hell out of window resizing in 10.2, so we don't have to worry about it, and no one can complain about window resizing speed.
<strong>1. Whenever the window size increases, the size of the offscreen buffer will need to increase. ... This could be really slow...
</strong><hr></blockquote>
Allocating the memory isn't that slow, it's just that when you're resizing you end up doing it a bunch of times. That's why some apps (the Finder in particular) pre-allocates all of the possible resize area so it doesn't have to keep doing it.
[quote]<strong>
2. Changing the width (pitch) of a window upsets this organization and forces the operating system to perform many copies to realign the rows (scanlines). This would also be very slow...
</strong><hr></blockquote>
This isn't that much of a problem, most of the time you have to re-render the contents due to the window changing sizes.
[quote]<strong>
3. I am guessing that all of the offscreen buffers are stored in system memory ... Ouch! However, I would assume that OpenGL games and multimedia are not automatically double buffered, so they don't see the same performance hit.
<hr></blockquote></strong>
OpenGL is full-screen so it doesn't have to deal with the compositing. Multimedia (you mean QT here I guess?) does. Moki has mentioned that you can bypass compositing but I haven't noticed any apps with hella fast refresh rates in a window.
[quote]<strong>
4. Every graphics operation requires an extra step. First the operation must be performed in the offscreen buffer and then the changes must be transferred (blit) to screen memory (framebuffer). In my experience, this extra blit should not be that big of a performance hit though.
<hr></blockquote></strong>
This is actually a huge performance hit, especially since Quartz generally has to repaint the entire window contents. The larger the area you're redrawing the slower it'll be (which is why a small Finder window will resize very nicely, but once you make it large it's much slower).
[quote]<strong>
4. Without double buffering, advanced visual effects like shadows, see through title bars (alpha channel), window thumbnails in dock, and opening window animations would be slow or impossible.
</strong><hr></blockquote>
None of those are what I'd consider advanced. Being able to set the translucency on an active window and have it update in real-time (like with the Terminal window) - that's advanced. I'm not sure whether it'll be worth it if there's a serious productivity impact on people who actually work with the hardware. Time will tell. I have this sneaking suspicion at least part of the decision on this was that it'd drive hardware sales, but maybe I'm just cynical .
[quote]<strong>
Preemptive multitasking alone could cause a substantial performance hit (which is why all of the old Photoshop bakeoffs are total bulls**t).
<hr></blockquote></strong>
I don't know about substantial given an advanced scheduler and a lightweight kernel (neither of which OS X really has). The Photoshop bakeoffs are hardly bullshît if you're someone who uses it. There aren't too many markets where the Mac dominates (or is even competitive) and this is going to hurt Apple.
[quote]<strong>
Personally, I'm glad they did not compromise features for performance. If you mess up your feature set in the beginning, it's hard to fix that later. </strong><hr></blockquote>
Well, given that Apple basically had a blank slate, it wouldn't have been too hard for them to do things like allow for outline resizing as an option (like some Carbon apps still do) and slowly roll in some of the more advanced features as time (and hardware) progresses.
I think there's at least some action that could be taken on current hardware (and every little bit helps) but I'm not sure that's a priority. Hopefully we'll see some really badass professional machines come out soon that will put all of this to rest, and then we can all just upgrade
"I regularly buffer my windows to protect them from other applications. Should I continue to do this if I use Quartz?
No. Core Graphics Services automatically buffers your windows so extra buffering is unnecessary and will negatively affect performance on Mac OS X." (Emphasis mine.)
Run the application QuartzDebug at /Developer/Applications/QuartzDebug.
Click on 'Show Window List'. The fourth column, on a *per window* basis, indicates whether or not the window is buffered.
</strong><hr></blockquote>
That's not related to double buffering the display you idiot.
<strong>Sorry Scott. Unless you can produce official documentation to validate your position, I'm going to have to say Brian's got you on this one.
</strong><hr></blockquote>
That's my whole point you stupid tool. We don't know how Apple does it. Brain started the topic, spouted crap out of his ass with no "official documentation" (which you can't seem to read, understand and relate to what's here), and then mentions me by name. So yea. I'll take him on. He's either wrong or making shit up or maybe does know but hasn't provided "official documentation".
So the onus is on him for "official documentation".
What is up man, I mean, Brian writes a page and a half of what looks to be very respectable [and completely understandable to the layman] explanation of his theory.
To which you respond with a one to two line response that consists of "no you are wrong because you are an idiot" what is up with that man?
That's my whole point you stupid tool. We don't know how Apple does it. Brain started the topic, spouted crap out of his ass with no "official documentation" (which you can't seem to read, understand and relate to what's here), and then mentions me by name. So yea. I'll take him on. He's either wrong or making shit up or maybe does know but hasn't provided "official documentation".
So the onus is on him for "official documentation".</strong><hr></blockquote>
ScottH,
You do you cause much harm by insisting on using personal attacks to make your point. I think BrianJ personally spoke to you becuse he knew you were going to have a LOT to say about what he was going to posit. You just took it personally becaue your name was mentioned. He however does one thing you do not. He says that he is only speculating and that he could be wrong. You are saying tat he cannot possibly be right and that you know FOR SURE that the screen is double buffered and not the Window only. Since you know this to be a fact, provide documents to say so. He does not know what he says for a fact, he is basing it off of what he has learned by actually programming a windowing environment. Have you done such a thing? If so it would lend a bit more credence to your case than the interspersed profanity and personal attacks do.
well, again, it's my opinion that the programmer should take the hurt instead of the user...
anyhow, first of all, i don't think it's the cause of the slow redraw because if double buffering causes the slow redraw on mac windows, then shouldn't ms windows windows that have double buffering programmed in also have the slow redraws? (but ms windows have all the advantages that you had listed)
it seems that double buffering can be put in the api, and doesn't need to be "built into the os" as it were. actually, unless i'm reading this wrong, double buffering is already part of kde system in the libs, and commenting/uncommenting the line just allows the window to take advantage of it. again, i stand by my assertion that it's not difficult to implement in osx in the future rather than now. so, because of this, i don't think that double buffering is the cause of the problem (because if it was, ms windows and x windows would have resizing problems if the programmer had programmed it in, and apple wouldn't give such a little shortcut to programmers with the noticeable performance hit to the end user)
[quote]<strong>I work out of my apartment. </strong><hr></blockquote>
Haha, me too. Beats traffic.
[quote]<strong>I am trying to get my own company off the ground and am working on my first product right now. I originally came here to work for Lucent (like almost everyone else who lives around here). Is that why you lived there?</strong><hr></blockquote>
I actually grew up around there and returned for a while after college. Worked for a couple years at Paramax in Red Bank. Now telecommute for Technovative Marketing Inc. (our top dogs our mostly ex at&t/lucent types). We'll if you ever get venture capitol and need marketing( someone to spend it for you ) give us a call. heh heh
Scott, not to belabor the obvious here, but here are your quotes that are *directly* contradicted by the documentation snippets I posted.
Provide *any* official documentation to the contrary, and you might be taken seriously.
[quote] The display is double buffered not the windows. Holy cow. <hr></blockquote>
[quote] Also you seem to think that each window is double buffered. It's the output frame that's double buffered. <hr></blockquote>
[quote] So, no, the windows are not double buffered. <hr></blockquote>
The windows are, on a per window basis, double buffered or not. Period. If you think otherwise, provide some proof.
Heck, provide anything stating that the display buffer as a whole is double buffered. It took me all of five minutes to find the snippets above. Surely you can find counterexamples if you're right.
Look you people have a tad on information and then think you're some kind of experct on why OS X sucks.
The window is rendered. It saved as a pixel map. Apple calls that buffered. Fine. That's not the double buffering of the dispaly. Different buffers. It's so simple I'm shocked people get it wrong.
Comments
<strong>Brian J.:
but...
...
...
...
i guess my point is, sure, it might be future-proofing, by the speed hit has caused more bad publicity than was worth it, in my humble opinion. generall double buffering code would be cut and pasteable anyhow. (or at least when learning directx, it's in the early chapters)
Ted</strong><hr></blockquote>
I've been hypothesizing so much... I'd like to test if double buffering really is the problem. I don't have much time now though.
But I agree. It is a tough call: Features or temporary sluggish performance??? IMHO, I'll take features as long as the slowdown is temporary. But then again, I am a very lazy programmer... Some graphic designers might think otherwise...
Let's hope Apple optimizes the hell out of window resizing in 10.2, so we don't have to worry about it, and no one can complain about window resizing speed.
[ 01-21-2002: Message edited by: Brian J. ]</p>
<strong>1. Whenever the window size increases, the size of the offscreen buffer will need to increase. ... This could be really slow...
</strong><hr></blockquote>
Allocating the memory isn't that slow, it's just that when you're resizing you end up doing it a bunch of times. That's why some apps (the Finder in particular) pre-allocates all of the possible resize area so it doesn't have to keep doing it.
[quote]<strong>
2. Changing the width (pitch) of a window upsets this organization and forces the operating system to perform many copies to realign the rows (scanlines). This would also be very slow...
</strong><hr></blockquote>
This isn't that much of a problem, most of the time you have to re-render the contents due to the window changing sizes.
[quote]<strong>
3. I am guessing that all of the offscreen buffers are stored in system memory ... Ouch! However, I would assume that OpenGL games and multimedia are not automatically double buffered, so they don't see the same performance hit.
<hr></blockquote></strong>
OpenGL is full-screen so it doesn't have to deal with the compositing. Multimedia (you mean QT here I guess?) does. Moki has mentioned that you can bypass compositing but I haven't noticed any apps with hella fast refresh rates in a window.
[quote]<strong>
4. Every graphics operation requires an extra step. First the operation must be performed in the offscreen buffer and then the changes must be transferred (blit) to screen memory (framebuffer). In my experience, this extra blit should not be that big of a performance hit though.
<hr></blockquote></strong>
This is actually a huge performance hit, especially since Quartz generally has to repaint the entire window contents. The larger the area you're redrawing the slower it'll be (which is why a small Finder window will resize very nicely, but once you make it large it's much slower).
[quote]<strong>
4. Without double buffering, advanced visual effects like shadows, see through title bars (alpha channel), window thumbnails in dock, and opening window animations would be slow or impossible.
</strong><hr></blockquote>
None of those are what I'd consider advanced. Being able to set the translucency on an active window and have it update in real-time (like with the Terminal window) - that's advanced. I'm not sure whether it'll be worth it if there's a serious productivity impact on people who actually work with the hardware. Time will tell. I have this sneaking suspicion at least part of the decision on this was that it'd drive hardware sales, but maybe I'm just cynical
[quote]<strong>
Preemptive multitasking alone could cause a substantial performance hit (which is why all of the old Photoshop bakeoffs are total bulls**t).
<hr></blockquote></strong>
I don't know about substantial given an advanced scheduler and a lightweight kernel (neither of which OS X really has). The Photoshop bakeoffs are hardly bullshît if you're someone who uses it. There aren't too many markets where the Mac dominates (or is even competitive) and this is going to hurt Apple.
[quote]<strong>
Personally, I'm glad they did not compromise features for performance. If you mess up your feature set in the beginning, it's hard to fix that later. </strong><hr></blockquote>
Well, given that Apple basically had a blank slate, it wouldn't have been too hard for them to do things like allow for outline resizing as an option (like some Carbon apps still do) and slowly roll in some of the more advanced features as time (and hardware) progresses.
I think there's at least some action that could be taken on current hardware (and every little bit helps) but I'm not sure that's a priority. Hopefully we'll see some really badass professional machines come out soon that will put all of this to rest, and then we can all just upgrade
<strong>From 'Quartz Primer', at <a href="http://developer.apple.com/techpubs/macosx/Essentials/QuartzPrimer.pdf"; target="_blank">http://developer.apple.com/techpubs/macosx/Essentials/QuartzPrim er.pdf</a> on page 9:
"I regularly buffer my windows to protect them from other applications. Should I continue to do this if I use Quartz?
No. Core Graphics Services automatically buffers your windows so extra buffering is unnecessary and will negatively affect performance on Mac OS X." (Emphasis mine.)
Run the application QuartzDebug at /Developer/Applications/QuartzDebug.
Click on 'Show Window List'. The fourth column, on a *per window* basis, indicates whether or not the window is buffered.
</strong><hr></blockquote>
That's not related to double buffering the display you idiot.
<strong>Sorry Scott. Unless you can produce official documentation to validate your position, I'm going to have to say Brian's got you on this one.
</strong><hr></blockquote>
That's my whole point you stupid tool. We don't know how Apple does it. Brain started the topic, spouted crap out of his ass with no "official documentation" (which you can't seem to read, understand and relate to what's here), and then mentions me by name. So yea. I'll take him on. He's either wrong or making shit up or maybe does know but hasn't provided "official documentation".
So the onus is on him for "official documentation".
What is up man, I mean, Brian writes a page and a half of what looks to be very respectable [and completely understandable to the layman] explanation of his theory.
To which you respond with a one to two line response that consists of "no you are wrong because you are an idiot" what is up with that man?
<strong>
That's my whole point you stupid tool. We don't know how Apple does it. Brain started the topic, spouted crap out of his ass with no "official documentation" (which you can't seem to read, understand and relate to what's here), and then mentions me by name. So yea. I'll take him on. He's either wrong or making shit up or maybe does know but hasn't provided "official documentation".
So the onus is on him for "official documentation".</strong><hr></blockquote>
ScottH,
You do you cause much harm by insisting on using personal attacks to make your point. I think BrianJ personally spoke to you becuse he knew you were going to have a LOT to say about what he was going to posit. You just took it personally becaue your name was mentioned. He however does one thing you do not. He says that he is only speculating and that he could be wrong. You are saying tat he cannot possibly be right and that you know FOR SURE that the screen is double buffered and not the Window only. Since you know this to be a fact, provide documents to say so. He does not know what he says for a fact, he is basing it off of what he has learned by actually programming a windowing environment. Have you done such a thing? If so it would lend a bit more credence to your case than the interspersed profanity and personal attacks do.
well, again, it's my opinion that the programmer should take the hurt instead of the user...
anyhow, first of all, i don't think it's the cause of the slow redraw because if double buffering causes the slow redraw on mac windows, then shouldn't ms windows windows that have double buffering programmed in also have the slow redraws? (but ms windows have all the advantages that you had listed)
also, looking at a small sample code,
<a href="http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html#ch09list02"; target="_blank">http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html#ch09list02</a>;
it seems that double buffering can be put in the api, and doesn't need to be "built into the os" as it were. actually, unless i'm reading this wrong, double buffering is already part of kde system in the libs, and commenting/uncommenting the line just allows the window to take advantage of it. again, i stand by my assertion that it's not difficult to implement in osx in the future rather than now. so, because of this, i don't think that double buffering is the cause of the problem (because if it was, ms windows and x windows would have resizing problems if the programmer had programmed it in, and apple wouldn't give such a little shortcut to programmers with the noticeable performance hit to the end user)
of course, like you, i'm pure speculation
Ted
[quote]<strong>I work out of my apartment. </strong><hr></blockquote>
Haha, me too. Beats traffic.
[quote]<strong>I am trying to get my own company off the ground and am working on my first product right now. I originally came here to work for Lucent (like almost everyone else who lives around here). Is that why you lived there?</strong><hr></blockquote>
I actually grew up around there and returned for a while after college. Worked for a couple years at Paramax in Red Bank. Now telecommute for Technovative Marketing Inc. (our top dogs our mostly ex at&t/lucent types). We'll if you ever get venture capitol and need marketing( someone to spend it for you
<strong>
ape already has made such sacrifices in 10.1
prime example:?</strong><hr></blockquote>
Shouldn't that be: primate example?
Provide *any* official documentation to the contrary, and you might be taken seriously.
[quote] The display is double buffered not the windows. Holy cow. <hr></blockquote>
[quote] Also you seem to think that each window is double buffered. It's the output frame that's double buffered. <hr></blockquote>
[quote] So, no, the windows are not double buffered. <hr></blockquote>
The windows are, on a per window basis, double buffered or not. Period. If you think otherwise, provide some proof.
Heck, provide anything stating that the display buffer as a whole is double buffered. It took me all of five minutes to find the snippets above. Surely you can find counterexamples if you're right.
[ 01-21-2002: Message edited by: Kickaha ]</p>
Kindof low, but still funny..
[ 01-25-2002: Message edited by: Whyatt Thrash ]</p>
<strong>[URL=http://www.winternet.com/~mikelr/flame63.html]</strong><hr></blockquote>;
Now that's a funny site!
The window is rendered. It saved as a pixel map. Apple calls that buffered. Fine. That's not the double buffering of the dispaly. Different buffers. It's so simple I'm shocked people get it wrong.