That is an awsome application! thanks for the heads up; now I know how old my computer is as well
For a zsh script version, see battery. It'll show you how that info is obtained with ioreg.
Before upgrading to 10.4 I had it running from cron every 30 minutes on my iBook G3, saving output to a log for a decent history of the battery capacity dissipation. Now that it's so low (7%) I haven't bothered doing that on 10.4, but will consider it again after I get a new battery.
I'm going to make a guess that the quad machines will ship with 10.4.3, and that's one reason why they were delayed until November. Unless I'm mistaken, this will be Apple's first quad-core machine, and the old DayStars were pre-MacOS X, so there are probably a few bugs to shake out from the kernel on up.
To chime in on the Quartz 2D Extreme, architectually it's the right way to go, but this kind of thing always tickles the obscure bugs in video drivers, compositors, and other graphics libraries. Also, depending on the application, it COULD be slower (if you draw a zillion small lines, the data for the lines could theoretically be more, and less cache localized, than the pixel data of the line itself.) But that type of thing will shake itself out, and become less important with things like PCIe. Once you have a pipe to the GPU as wide as PCIe, a lot of these optimizations become less important anyway, though. (I suspect MacOS X will benefit more from PCIe than most Windows machines because of all the compositing and Core Imaging MOSX does.)
Also, depending on the application, it COULD be slower (if you draw a zillion small lines, the data for the lines could theoretically be more, and less cache localized, than the pixel data of the line itself.) But that type of thing will shake itself out, and become less important with things like PCIe. Once you have a pipe to the GPU as wide as PCIe, a lot of these optimizations become less important anyway, though. (I suspect MacOS X will benefit more from PCIe than most Windows machines because of all the compositing and Core Imaging MOSX does.)
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
Try it with Q2DE enabled though and it's embarrassing.
That's a good point, I forgot about it.
Of course, the 5200 series is rather outdated now. That's why it's too bad that Apple has been sticking with these old chips. The newer chips are more programmable than the 5200 and 9600 series are though. We'll have to see what happens there.
Of course, the 5200 series is rather outdated now. That's why it's too bad that Apple has been sticking with these old chips. The newer chips are more programmable than the 5200 and 9600 series are though. We'll have to see what happens there.
I'm sure it's going to improve as Windows Vista will hit the exact same problems but even some of the cards used now in Macs aren't that much different to the 5200 or 9600. The X600 in the new iMac isn't that great a leap up in performance here.
It'll be odd to watch a renaissance in 2D card performance but certainly welcome from this quarter. Text scrolling speed has annoyed me for ages on OSX - it may be nicely rendered, accurate and kerned but fullscreen vga in dos or linux just rules for text speed, even on computers 10+ years old running old 2MB cards.
I'm sure it's going to improve as Windows Vista will hit the exact same problems but even some of the cards used now in Macs aren't that much different to the 5200 or 9600. The X600 in the new iMac isn't that great a leap up in performance here.
It'll be odd to watch a renaissance in 2D card performance but certainly welcome from this quarter. Text scrolling speed has annoyed me for ages on OSX - it may be nicely rendered, accurate and kerned but fullscreen vga in dos or linux just rules for text speed, even on computers 10+ years old running old 2MB cards.
Yeah. You'd think we could have fast AND pretty by now.
The problem with this is not that Apple couldn't do it. The problem is that they chose a way to do it that ended up being slow. Not quite the same as, but similiar to the Window stretch redraw problem.
It's been a while since I involved myself with that so I don't remember exactly how they did this. But Apple found other advantages in doing the routines the way they did that apparently was more important to them.
Q2DE is supposed to speed up both of these actions tremendously by utilizing the 3D programmability in the boards. That SHOULD work fine, as most of the work being done at the time when these routines are being done is 2D, which is easy for almost any modern board.
But obviously Apple has been having problems. I'm not going to judge it until it's official.
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
This is strange, the low level benchmarks performed by apple and even an Xbench run show that the text rendering speed is quite improved by Q2DX.
They HAVE improved over 10.3. Before 10.4 the quickest way to do text was with the old Quickdraw routines. The issue now is that the new routines are quicker with Q2DE disabled than enabled.
XBench scores are lower with Q2DE enabled on my iMac are lower in both the text scroll and UI tests. It's not as big a difference as the javascript test above but it's significant enough. And I notice it being slower in BBEdit or Subethaedit personally.
I'm willing to admit the FX5200 in the iMac isn't the fastest of cards but it's also not really a slouch in the grand scheme of things and faster than many cards which will still be in use or even still shipping in some of the current Mac models.
Indeed, it depends on the GPU you have. Some geforce 6800 owner reported a big improvement in the text drawing test (Xbench). Apple says QD2X improves the text drawing speed (2.7x) compared to quartz, under tiger. We don't know which GPU they had though.
Indeed, it depends on the GPU you have. Some geforce 6800 owner reported a big improvement in the text drawing test (Xbench). Apple says QD2X improves the text drawing speed (2.7x) compared to quartz, under tiger. We don't know which GPU they had though.
I forgot all about that article. It's the best explaination around.
That is what ARs is best at. Explaining the technicalities.
I always reccomend that Mac users use their site. There are 3 or 4 Mac baiters there, but otherwise, it very Mac friendly. There is a Mac area as well.
The point about programs needing to be modified to take advantage of this is a good one. The amount of VRAM is as well.
Keep in mind that Q2DE is targeted at more than just speeding up rendering.
One of it's primary goals is to decrease load on the rest of the system by tapping into previously unused GPU power. Some users would prefer a slight decrease in text rendering speed if it was accompanied by a decrease in processor usage.
I for one can't wait for Q2DE to be ready for prime time. I've run with it on for extended periods of time (weeks). Ironically, I can no longer seem to tell whether it is enabled or not. Perhpas the speed-up I originally perceived was placebo induced. Not that it doesn't speed things up... just that I couldn't tell in my daily tasks.
One of it's primary goals is to decrease load on the rest of the system by tapping into previously unused GPU power. Some users would prefer a slight decrease in text rendering speed if it was accompanied by a decrease in processor usage.
I don't see how that is acceptable if you're running a text editor or wordprocessor frontmost. The most important thing there is text rendering speed. Nothing else matters.
I don't see how that is acceptable if you're running a text editor or wordprocessor frontmost. The most important thing there is text rendering speed. Nothing else matters.
One of the problems is that scrolling speed is dependent on the finder, as is window redraw. The finder has always been the rear end of OS X (to be nice). Built in Carbon, it's been out of sync with the rest of the OS. The problem is also with Quickdraw.
These problems would go away if Apple finally rewrote in in Cocoa.
One of the problems is that scrolling speed is dependent on the finder, as is window redraw. The finder has always been the rear end of OS X (to be nice). Built in Carbon, it's been out of sync with the rest of the OS. The problem is also with Quickdraw.
These problems would go away if Apple finally rewrote in in Cocoa.
I don't see how the Finder is the problem here, or Carbon. If you're in Safari or most text editors it's not the Finder and it's usually an NSTextView. That's not to say Finder doesn't need a ground up rewrite.
I've taught myself to use page up/down more than I did in the past to solve scrolling problems.
I don't see how the Finder is the problem here, or Carbon. If you're in Safari or most text editors it's not the Finder and it's usually an NSTextView. That's not to say Finder doesn't need a ground up rewrite.
I've taught myself to use page up/down more than I did in the past to solve scrolling problems.
Read the article French posted. I re-read it. It explains a lot of things.
Comments
Originally posted by kaiwai
That is an awsome application! thanks for the heads up; now I know how old my computer is as well
For a zsh script version, see battery. It'll show you how that info is obtained with ioreg.
Before upgrading to 10.4 I had it running from cron every 30 minutes on my iBook G3, saving output to a log for a decent history of the battery capacity dissipation. Now that it's so low (7%) I haven't bothered doing that on 10.4, but will consider it again after I get a new battery.
To chime in on the Quartz 2D Extreme, architectually it's the right way to go, but this kind of thing always tickles the obscure bugs in video drivers, compositors, and other graphics libraries. Also, depending on the application, it COULD be slower (if you draw a zillion small lines, the data for the lines could theoretically be more, and less cache localized, than the pixel data of the line itself.) But that type of thing will shake itself out, and become less important with things like PCIe. Once you have a pipe to the GPU as wide as PCIe, a lot of these optimizations become less important anyway, though. (I suspect MacOS X will benefit more from PCIe than most Windows machines because of all the compositing and Core Imaging MOSX does.)
Originally posted by Booga
Also, depending on the application, it COULD be slower (if you draw a zillion small lines, the data for the lines could theoretically be more, and less cache localized, than the pixel data of the line itself.) But that type of thing will shake itself out, and become less important with things like PCIe. Once you have a pipe to the GPU as wide as PCIe, a lot of these optimizations become less important anyway, though. (I suspect MacOS X will benefit more from PCIe than most Windows machines because of all the compositing and Core Imaging MOSX does.)
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
The test which I've ran which most exhibits this behaviour is test 6 at http://www.24fun.com/downloadcenter/...s/benchjs.html which is already slow on a Mac.
Try it with Q2DE enabled though and it's embarrassing.
Originally posted by aegisdesign
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
The test which I've ran which most exhibits this behaviour is test 6 at http://www.24fun.com/downloadcenter/...s/benchjs.html which is already slow on a Mac.
Try it with Q2DE enabled though and it's embarrassing.
That's a good point, I forgot about it.
Of course, the 5200 series is rather outdated now. That's why it's too bad that Apple has been sticking with these old chips. The newer chips are more programmable than the 5200 and 9600 series are though. We'll have to see what happens there.
Originally posted by melgross
That's a good point, I forgot about it.
Of course, the 5200 series is rather outdated now. That's why it's too bad that Apple has been sticking with these old chips. The newer chips are more programmable than the 5200 and 9600 series are though. We'll have to see what happens there.
I'm sure it's going to improve as Windows Vista will hit the exact same problems but even some of the cards used now in Macs aren't that much different to the 5200 or 9600. The X600 in the new iMac isn't that great a leap up in performance here.
It'll be odd to watch a renaissance in 2D card performance but certainly welcome from this quarter. Text scrolling speed has annoyed me for ages on OSX - it may be nicely rendered, accurate and kerned but fullscreen vga in dos or linux just rules for text speed, even on computers 10+ years old running old 2MB cards.
Originally posted by aegisdesign
I'm sure it's going to improve as Windows Vista will hit the exact same problems but even some of the cards used now in Macs aren't that much different to the 5200 or 9600. The X600 in the new iMac isn't that great a leap up in performance here.
It'll be odd to watch a renaissance in 2D card performance but certainly welcome from this quarter. Text scrolling speed has annoyed me for ages on OSX - it may be nicely rendered, accurate and kerned but fullscreen vga in dos or linux just rules for text speed, even on computers 10+ years old running old 2MB cards.
It rules in OS 9 as well unfortunately.
Originally posted by melgross
It rules in OS 9 as well unfortunately.
Yeah. You'd think we could have fast AND pretty by now.
Originally posted by aegisdesign
Yeah. You'd think we could have fast AND pretty by now.
The problem with this is not that Apple couldn't do it. The problem is that they chose a way to do it that ended up being slow. Not quite the same as, but similiar to the Window stretch redraw problem.
It's been a while since I involved myself with that so I don't remember exactly how they did this. But Apple found other advantages in doing the routines the way they did that apparently was more important to them.
Q2DE is supposed to speed up both of these actions tremendously by utilizing the 3D programmability in the boards. That SHOULD work fine, as most of the work being done at the time when these routines are being done is 2D, which is easy for almost any modern board.
But obviously Apple has been having problems. I'm not going to judge it until it's official.
Originally posted by aegisdesign
The big problem so far seems to be fonts. As I understand it Q2DE caches a rendered version of any characters it's used and blits them onto the screen using the GPU. This seems to be much slower than drawing the characters using the CPU and traditional font metrics. GPUs have been driven over the years by games mostly so are extremely fast at 3D, texture mapping, shading etc but seem to be 'terrible' at rendering fonts relatively and more general purpose CPUs can do it much quicker.
From my testing it's as much as 30 times slower on a fairly average FX5200 in comparison to a 1.8Ghz G5, which is a pity as there's massive speedups elsewhere. I'm not sure where the solution lies - more tightly optimized GPU code or mixing CPU and GPU rendering based on context intelligently. I imagine that's a very tricky balance.
The test which I've ran which most exhibits this behaviour is test 6 at http://www.24fun.com/downloadcenter/...s/benchjs.html which is already slow on a Mac.
Try it with Q2DE enabled though and it's embarrassing.
This is strange, the low level benchmarks performed by apple and even an Xbench run show that the text rendering speed is quite improved by Q2DX.
Originally posted by french macuser
This is strange, the low level benchmarks performed by apple and even an Xbench run show that the text rendering speed is quite improved by Q2DX.
They HAVE improved over 10.3. Before 10.4 the quickest way to do text was with the old Quickdraw routines. The issue now is that the new routines are quicker with Q2DE disabled than enabled.
XBench scores are lower with Q2DE enabled on my iMac are lower in both the text scroll and UI tests. It's not as big a difference as the javascript test above but it's significant enough. And I notice it being slower in BBEdit or Subethaedit personally.
I'm willing to admit the FX5200 in the iMac isn't the fastest of cards but it's also not really a slouch in the grand scheme of things and faster than many cards which will still be in use or even still shipping in some of the current Mac models.
http://arstechnica.com/reviews/os/macosx-10.4.ars/14
Originally posted by french macuser
Indeed, it depends on the GPU you have. Some geforce 6800 owner reported a big improvement in the text drawing test (Xbench). Apple says QD2X improves the text drawing speed (2.7x) compared to quartz, under tiger. We don't know which GPU they had though.
http://arstechnica.com/reviews/os/macosx-10.4.ars/14
I forgot all about that article. It's the best explaination around.
That is what ARs is best at. Explaining the technicalities.
I always reccomend that Mac users use their site. There are 3 or 4 Mac baiters there, but otherwise, it very Mac friendly. There is a Mac area as well.
The point about programs needing to be modified to take advantage of this is a good one. The amount of VRAM is as well.
One of it's primary goals is to decrease load on the rest of the system by tapping into previously unused GPU power. Some users would prefer a slight decrease in text rendering speed if it was accompanied by a decrease in processor usage.
I for one can't wait for Q2DE to be ready for prime time. I've run with it on for extended periods of time (weeks). Ironically, I can no longer seem to tell whether it is enabled or not. Perhpas the speed-up I originally perceived was placebo induced. Not that it doesn't speed things up... just that I couldn't tell in my daily tasks.
powerbook 1.33 radeon 9700 (64 mb) with \t 21.59 seconds
without 19.34 seconds,
obliviousy q2de has problems. one of these is the lack of opengl 2 on tiger
i really hope that apple finally give us all the feature we have paid for
Originally posted by gelosilente
well, i have make the test with and without q2de:
powerbook 1.33 radeon 9700 (64 mb) with \t 21.59 seconds
without 19.34 seconds,
obliviousy q2de has problems. one of these is the lack of opengl 2 on tiger
i really hope that apple finally give us all the feature we have paid for
Apple has given us all the features we have paid for. This is an extra, and when it's ready, we'll get it too.
Originally posted by dfiler
One of it's primary goals is to decrease load on the rest of the system by tapping into previously unused GPU power. Some users would prefer a slight decrease in text rendering speed if it was accompanied by a decrease in processor usage.
I don't see how that is acceptable if you're running a text editor or wordprocessor frontmost. The most important thing there is text rendering speed. Nothing else matters.
Originally posted by aegisdesign
I don't see how that is acceptable if you're running a text editor or wordprocessor frontmost. The most important thing there is text rendering speed. Nothing else matters.
One of the problems is that scrolling speed is dependent on the finder, as is window redraw. The finder has always been the rear end of OS X (to be nice). Built in Carbon, it's been out of sync with the rest of the OS. The problem is also with Quickdraw.
These problems would go away if Apple finally rewrote in in Cocoa.
Originally posted by melgross
One of the problems is that scrolling speed is dependent on the finder, as is window redraw. The finder has always been the rear end of OS X (to be nice). Built in Carbon, it's been out of sync with the rest of the OS. The problem is also with Quickdraw.
These problems would go away if Apple finally rewrote in in Cocoa.
I don't see how the Finder is the problem here, or Carbon. If you're in Safari or most text editors it's not the Finder and it's usually an NSTextView. That's not to say Finder doesn't need a ground up rewrite.
I've taught myself to use page up/down more than I did in the past to solve scrolling problems.
Originally posted by aegisdesign
I don't see how the Finder is the problem here, or Carbon. If you're in Safari or most text editors it's not the Finder and it's usually an NSTextView. That's not to say Finder doesn't need a ground up rewrite.
I've taught myself to use page up/down more than I did in the past to solve scrolling problems.
Read the article French posted. I re-read it. It explains a lot of things.
Originally posted by melgross
Read the article French posted. I re-read it. It explains a lot of things.
Though not why text is slower, which is the only thing slower in Q2DE than Q2D and is my major bone of contention.