[Krypton]

How would I go about turning window buffering off? I realise this will make dragging windows and resizing very flickery, but I'm curious as to what kind of speed up this produces.

[foamy]

You might ask over at the Ambrosia Software forums.

I distinctly remember someone there saying that games often override double-buffering. Having said that, you might be out of luck if it has to be coded into the application.

IANA Programmer, so I have no idea!

[TETENAL]

You can not turn off window buffering in Mac OS X.

[chabig]

Window buffering cannot be turned off. But if you could you wouldn't get a speedup. Rather, your machine would likely be slower because the CPU would have to keep redrawing the contents of the windows.

Chris

[Krypton]

Originally posted by chabig:
Window buffering cannot be turned off. But if you could you wouldn't get a speedup. Rather, your machine would likely be slower because the CPU would have to keep redrawing the contents of the windows.

Chris

Well, if you look at Windows an old cpu can still resize windows in real time, but tends to miss out the redraws it can't manage - hence the flicker.

[P]

It would not be faster. You would however save some memory, but I doubt that you can do it - OS X assumes that the window server uses double-buffered windows, and you will likely break things by disabling this.

[qnxde]

I think you can turn it off on an app-by-app basis, I'm sure I've seen an option in interfacebuilder to disable it for a specific window...

[larkost]

Just so that everything is clear: MacOS X double buffers most windows by default. All windows are single buffered (you cannot draw directly to the frame buffer... you can't even address that hardware). Double buffering is not so much a slow-down (in fact it can speed things up in some cases... especially if you are not a computer graphics specialist), as it just uses up more memory (as others have already pointed out).

When you are developing an application you can very easily choose whether a window should be single or double buffered, but that is usually only important if you have large graphics objects, such as OpenGL objects (which get their second buffer in the Graphics Card usually).

Executive summary: you can't turn off double buffering from an end user standpoint, and even if you could it would probably hurt you more than it would help.


Side note: The whole MS Windows resizing vs. MacOS X resizing is a very complicated thing. The very few applications that react to sizing the way that default MacOS X applications do have incredibly poor refresh rates in Windows and tend to tear a lot... not to mention the absolutely horrible way that things tend to not get refreshed when an app is busy... which leads to "ghosts". This almost never happens on MacOS X (I have seen it once when a graphics driver was in the process of crashing... but that was really my fault for doing very bad things to it at the time...).

And the really funny thing is that Microsoft is working on copying the approach that Apple is using.. and it is giving them fits... to the point where the first version of Longhorn probably will not have it, and it will be an "optional" add-on sometime after the OS comes out. WindowsME all over again...

[bmedina]

Or you could just run OS 9.

[msuper69]

+

[CharlesS]

Originally posted by qnxde:
I think you can turn it off on an app-by-app basis, I'm sure I've seen an option in interfacebuilder to disable it for a specific window...

But have you ever tried actually doing this? If you do, you'll be in for a bit of a surprise...

[jasong]

What surprise would that be? I'm not a programmer so I'll never find out if you don't tell me . . .

-- Jason

[Chuckit]

The surprise is that unless an app is specifically coded for it, turning off the normal buffering will really screw up drawing and kill any transparency on the window (including rounded corners).

[Toyin]

I still haven't heard a good explanation why OSX window resizing is so slow compared to Windows. The potential is obviously there in OSX. Have any of you tried resizing a window in VLC player? I use version 0.7.2 and this application resizes video while playing videos on the fly better than ANY application in OSX. It resizes faster than a blank Text Edit window. In fact VLC 0.7.2 resizes better than any application that I've used in Windows. There is no flickering, no mouse lag, and the video keeps playing smoothly without dropping frames. The other place I see decent resizing in OSX is when using X11 applications. Refresh rates are slower than OSX but there's no mouse lag.

Can any explain in layman's terms what makes VLC tick, and why other's can't copy it?

note: VLC 0.8x builds have lost the great resizing. Also I'm using a 15"PB 1.5ghz with 128MB Radeon

[Amorya]

Originally posted by Toyin:
I still haven't heard a good explanation why OSX window resizing is so slow compared to Windows.

People still find OSX window resizing slow? :o

It's certainly as fast as Windows on my 1Ghz AlBook... in Omniweb (just tested) the resizing doesn't lag behind the mouse pointer at all.

Got any specs for your machine?


Amorya

[Catfish_Man]

Originally posted by Amorya:
People still find OSX window resizing slow? :o

It's certainly as fast as Windows on my 1Ghz AlBook... in Omniweb (just tested) the resizing doesn't lag behind the mouse pointer at all.

Got any specs for your machine?


Amorya

Most people still find it slow, ime. However, most that I've talked to have also said that 10.4 is immensely better in this area.

[tkmd]

I have a copy of 10.0 I could give you

[Toyin]

Originally posted by Amorya:
People still find OSX window resizing slow? :o

It's certainly as fast as Windows on my 1Ghz AlBook... in Omniweb (just tested) the resizing doesn't lag behind the mouse pointer at all.

Got any specs for your machine?


Amorya

1.5ghz AlBook, 1gb Ram, 128MB Radeon. Just tried Omniweb and while it's resizing is better than Safari there is still a noticeable lag when compared to VLC and resizing on Windows machines. I find resizing tolerable in Panther, but there's a lot of room for improvement

Originally posted by tkmd:
I have a copy of 10.0 I could give you

Ahhh, the good old days, I've still got the Public Beta lying around. I remember the day that 10.0 came out and how disappointed I was that Kosmos' mysterious, blazingly fast build didn't exist.

[qnxde]

Originally posted by CharlesS:
But have you ever tried actually doing this? If you do, you'll be in for a bit of a surprise...

Nah, I've never actually written a line of real code in my life - I just saw the option while poking through the inspector.

[qnxde]

Originally posted by CharlesS:
But have you ever tried actually doing this? If you do, you'll be in for a bit of a surprise...

Nah, I've never actually written a line of real code in my life - I just saw the option while poking through the inspector.

[juanvaldes]

You dont need to write a single line.

Just open up Interface Builder, create a new interface. Select the window, bring up the inspector, goto Attributes and change the Backing. Then hit command-R to test the interface.

[tooki]

Originally posted by Toyin:
I still haven't heard a good explanation why OSX window resizing is so slow compared to Windows. The potential is obviously there in OSX. Have any of you tried resizing a window in VLC player? I use version 0.7.2 and this application resizes video while playing videos on the fly better than ANY application in OSX. It resizes faster than a blank Text Edit window.

On my PowerBook, a blank TextEdit window decidedly resizes faster than even VLC 0.7.2. Of course, since Apple DVD Player doesn't allow arbitrary window resizing, we can't compare how well it fares. My hunch is that because Apple's player is highly optimized and accelerated, it would resize very quickly.

As for why VLC resized faster: with modern graphics cards, video resizing can be completely handed off to the graphics cards (that's what Expos� does with all windows). All VLC would have to do is tell the graphics card "Yo graphics card, here's the current window dimensions. Oh wait, they changed, here are the new ones." A program like Safari must actually re-draw the contents of the window before anything can be sent to the graphics card. VLC gets the luxury of sending the decoded video stream right to the graphics card and letting it do all the work from there.

tooki

[Toyin]

Originally posted by tooki:
On my PowerBook, a blank TextEdit window decidedly resizes faster than even VLC 0.7.2. Of course, since Apple DVD Player doesn't allow arbitrary window resizing, we can't compare how well it fares. My hunch is that because Apple's player is highly optimized and accelerated, it would resize very quickly.

As for why VLC resized faster: with modern graphics cards, video resizing can be completely handed off to the graphics cards (that's what Expos� does with all windows). All VLC would have to do is tell the graphics card "Yo graphics card, here's the current window dimensions. Oh wait, they changed, here are the new ones." A program like Safari must actually re-draw the contents of the window before anything can be sent to the graphics card. VLC gets the luxury of sending the decoded video stream right to the graphics card and letting it do all the work from there.

tooki

Makes some sense. I just tired VLC (with a 40mb mpg music video) and it resizes faster than text edit. Looking at the CPU monitor it seems that brief resizes does nothing to the CPU (supporting your theory). However if I keep resizing for several seconds the CPU usage does increase.

Whatever the reason, Windows 2000 professional on my 500mhz PIII can re-draw the contents of a web browser as well as my 1.5ghz PB. It's not even a comparison with the 2.8ghz PIV at work, which resizes iTunes windows significantly better than my PB.

[P]

Originally posted by tooki:
On my PowerBook, a blank TextEdit window decidedly resizes faster than even VLC 0.7.2. Of course, since Apple DVD Player doesn't allow arbitrary window resizing, we can't compare how well it fares. My hunch is that because Apple's player is highly optimized and accelerated, it would resize very quickly.

As for why VLC resized faster: with modern graphics cards, video resizing can be completely handed off to the graphics cards (that's what Expos� does with all windows). All VLC would have to do is tell the graphics card "Yo graphics card, here's the current window dimensions. Oh wait, they changed, here are the new ones." A program like Safari must actually re-draw the contents of the window before anything can be sent to the graphics card. VLC gets the luxury of sending the decoded video stream right to the graphics card and letting it do all the work from there.

tooki

Sort of. Apple is cheating a bit when resizing windows - you can see the traces of it in QuartzDebug. Try resizing a Finder window. What really happens is that the Finder redraws the largest possible window - ie from it's current position all the way down to the lower right corner - and then sets the opacity to 0 for the hidden parts. When moving the corner, you're only changing the opacity, so the Finder doesn't have to do anything. The Windowserver does it all, and it's much quicker to just redraw the pixels than to figure out what they are supposed to be first. This feature does not rely on QE - my old iMac DV does the same thing - but I expect that the graphics board is used if it supports that feature. Safari, and for that matter IE and any program that tries to redraws while resizing, have to redraw that background picture all the time and are much slower because they don't know what it is going to be beforehand.

[TETENAL]

Huh?

I can't say I undestood what you were saying, but for sure the Finder doesn't do that.

[Tyler McAdams]

You could use somethimg like this to speed up the formost app in os x:

http://www.apple.com/downloads/macos...celerator.html

That will at least give a little speed to an old mac running os x... not too sure if it will help with window resizing tho...

[tooki]

Originally posted by P:
Sort of. Apple is cheating a bit when resizing windows - you can see the traces of it in QuartzDebug. Try resizing a Finder window. What really happens is that the Finder redraws the largest possible window - ie from it's current position all the way down to the lower right corner - and then sets the opacity to 0 for the hidden parts. ...

Maybe in icon view it does that, but in list view, live resizing is horrifically slow, considering how little it has to draw.

tooki