AltiVec can be pretty nice, but it's got a serious limitation. The G4's memory bandwidth is a paltry 1.3 GB/sec (shared by two processors on most PowerMacs). If you consider that a single vector takes up 16 bytes, then a single AltiVec unit can theoretically chew through 16 gigabytes of data per second. Even if you take into account the G4's L3 cache (1-2MB @ 4GB/sec) the G4 has nowhere near the bandwidth of a P4, which has 4.2 GB/sec to main memory. At that point, it doesn't matter if the AltiVec unit is ten times as fast as the P4. Unless the data fits mostly in the caches, both processors will be memory bandwidth limited. This situation favors the x86 chips, because recently, memory bandwidth has been climbing very quickly. By Q3-2003, x86 chips will hit 6.4GB/sec of main memory bandwidth.
Intel provides a nice, really easy to use C++ vector library as well. It provides C++ vector datatypes that make working with vectors the same as working with regular floats.
Doh. The typing test would be better without the spelling and grammer mistakes in the text...
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 2, Interesting
As a long time KDE user, I have to say it really isn't. KDE seems much more Mac (classic Mac, not OS X) to me than anything else. The KDE-bundled applications are very non-Windows like. They tend to be simple and streamlined, rather than bloated and complex. KWord, for example, is very elegant, like WordPerfect, rather than like MS Word.
The sad thing is that a 1.25 Ghz Alpha is competitive with the new IBM 970 (a 3Ghz P4 is slightly faster, both in integer and floating point). Damn it. Just release a 1.8 Ghz Alpha on a 0.13 SOI process and take over the world. How hard can it be!
Just used it the day before yesterday (10.2.1) on a G4-800 MHz. Still bloody slow. The 2GHz P4's running Win2K next to it are much faster, and were probably cheaper... If you think OS X on a G3-400 MHz is usable, you must either be very old, or already dead.
Well, I had the same problem, and setting IgnoreEDID it fixed it for me. For reference, I was running an Athlon XP 1700 on a SiS motherboard with a GeForce2 MX. On my Inspiron 8200 with GeForce4 MX, I don't have any problem at all. So it must be something with your particular configuration.
New stuff is expensive. But new stuff makes old stuff be cheaper. Right now, a GF4 Ti 4200 can be had for just over $100. It's a great buy, and at that price, you can afford to upgrade much more often. Of course, there are people that actually do need this kind of power (the vertex and pixel shaders are amazing, just from a programming point of view) and they're willing to pay for it.
Are you using multi-head by any chance? The TwinView code seems to be kinda flaky. Also, are you running the 4191 drivers, which have some major architectural changes and are thus kinda flaky. I've been using NVIDIA's Linux drivers back before it was cool (on a TNT-1) and they've been perfectly stable.
PS> NVIDIA is in no position to open their drivers. We're not talking a NIC card driver here. An OpenGL ICD is the whole OpenGL subsystem. NVIDIA's "drivers" total about 5-6MB, and includes kernel and XFree drivers, GLX module, and GL and GLU libraries. There is a whole lot of high level stuff in there that 1) NVIDIA doesn't own all the IP to and 2) Could really help out manufacturers with sucky drivers (*cough* ATI *cough*).
Actually, that's not general crapiness in the drivers. That has to do with a very long monitor mode probing that's going on. You can relieve the problem by setting the IgnoreEDID field in XF86Config (in the NVIDIA section). That said, the 4191 is quite buggy. To be fair, they are moving to an entirely new 2D architecture (moving from XAA to their own design) so weirdness is to be expected. I just wish they had labled the drivers "beta" or something. All the other drivers (I've been using them since the first release) have been very stable, however. I recommend sticking with 3123 for the time being.
/. seems to have become the home of a bunch of pansies. "My iMac doesn't have a fan!" "The fan noise is too loud!" "My ears are bleeding!" Bah. You're all sissies. I'm an Inspiron 8200 owner. It burns my lap and punctures my eardrums with fan noise! I have to turn my 400-watt Klipschs all the way up just to hear music! And I *like* it that way! This new GPU fan isn't so bad. I've got a 7000 RPM fan on my Athlon back home, and not only can I hear the jet-turbine noise in another room, I can hear it on another floor! And I *like* it that way! So bring it on NVIDIA! It's not like I can hear the damn thing anyway!
I just played Rogue Leader this afternoon, and I can still see polygons. FFX is one of the first games in which I almost forgot that the characters are polygonal. There is no doubt, of course, that the GPUs in the XBox and GC are more powerful, but it's an acknowledged fact that the GC simply doesn't have the poly-pushing capability of the other consoles. Even Nintendo's official line is that the GC is easy to program, but still "performance competitive".
The higher your max capabilities, the better the lower ones get. Since the parent to my post said 1920x1440, there's a good chance it'll hit at least 75Hz at that resolution. >>>>>>>>> 75 Hz is too low, and besides, even then 1920x1440 is only 120 dpi. Like I said, I have yet to see a CRT than can match the resolution and image stability of my Dell LCD.
Actually, the GC doesn't have better hardware, because it's main CPU lacks vector units. The PS2 simply has more floating point power available, there's no debating that. I've seen StarFox Adventures, and I'm really not impressed at all. It has nice special effects, but to my eyes, detailed modeling is more important at this ti
Even Metriod Prime, which has the best graphics of any GC game, has noticibly low poly models (especially the terrain). The gamecube could *not* push all the polygons in FFX. I've seen screenshots of PN:03, and they suffer from the same weakness of all gamecube games: low poly environments.
Actually, the PS2 has more VRAM than the Gamecube (4MB vs 3MB). The major problem is that the PS2's graphics chip doesn't do anti-aliasing or as many special effects. Either way, it's much less important for the PS2, which is designed to stream textures rather than cache them in VRAM. Read the ArsTechnica article for more info on the PS2 architecture. As for the color palatte, it's all 16 or 32 bit color, the PS2 doesn't accelerate palettized modes.
The problem with resolutions that high on CRTs is that it tends to make the image very grainy. I know pushing my 19" up to 1600x1200 noticibly reduces quality. I haven't seen any 19" CRTs that have a recommended resolution higher than 1280x1024. And no CRT will go to 1920x1440 with 85+ Hz, which I find is the absolute minimum for a decently stable image. I prefer mine to be 90-100 Hz, since I'm quite sensitive to flicker, but no CRT I've seen approaches the (perfect) image stability of my LCD.
I refuse to buy a monitor that doesn't have at least a 120 DPI native resolution. That rules out pretty much every CRT. I switched from a nice 19" Sony Trinitron to a 15" 1600x1200 Dell laptop LCD, and it's the best switch I've ever made. Staring at text just plain becomes easier when there are enough pixels to actually display letter shapes! The total lack of flicker and zero geometric distortion doesn't hurt!
Actually, it's less advanced than the PS2. The graphics processor has more features, but the PS2 has insane vector processing capabilities, which let's it push insane polygons. The Gamecube hardware can drive some nifty special effects, but the PS2 can make some genuinely good looking games (FF-X would not be possible on GC).
Look, I like documentation as much as the next guy. But we're talking less than two dozen lines of code here! The point your missing is that Xft isn't supposed to be the definitive reference on this (unlike the RFC). All the information is available elsewhere. All that is needed is a note saying that Xft uses a "simple intra-pixel filter" (quote from the Xft documentation) and the specific filter used. Publishing an article about the technique used in Xft would be like publishing an article about how your project uses compiler options in its build!
PS> I'm not an EE. If I was, I'd probably know what your code sample did. I am, however, pretty well versed in typography and imaging, so it was easy for me to figure out what the Xft code did. It is assumed, when dealing with code like this, that the reader has at least a basic knowledge of the problem domain.
The internet is a great place to make money. Companies that understand this, like Dell, Apple, IBM, the various online retailers, etc, are in a powerful position. I have personally spent thousands of dollars online, and now do almost all my major purchases on the internet. If music was conveniently available online, a chunk of that money would go the RIAAs way. But since it isn't, well, too bad for them.
I have no idea. You didn't give me any context, and your variable names suck. With the Xft code, however, there is a whole lot of context. You know you're applying a certain filter to the pixels of the bitmap. Applying filters is a well known technique. There are lots of digital signal processing packages out there that will do it for you. Right at the top of xftglyphs.c is a variable named "filters" that tell you exactly what filters are being applied. That's all you need to know. There is no point publishing a paper when the process is so well known to those working in the field.
Actually, there are no monitors out there that are high res enough to abandon hinting. My LCD is as high-res as you can get without going to Roentgen (1600x1200 - 15" = 133 dpi) and even then at least minimal hinting is required to get good looking fonts. OS X fonts (IMO) look shitty. The major problem is the color. 'Color' is typography-speak for the evenness of the weight of the strokes along the line. Hinting mechanisms make sure there is roughly an even amount of black in any given area along the line. This makes reading much smoother. Without hinting, proper color is just shot. Then there is the problem that without hinting fonts are far too fuzzy to be comfortably readable. One thing OS X fonts *do* have (and which people swoon over at demos, until they actually have to stare at them for 8 hours a day) is really good letter shape, because no hinting (read: deformation) is done for the sake of legibility. However, minimal hinting can be done to improve legibility a huge amount, without sacrificing too much from the letter shape.
Um, unlike ClearType, you can just go read the code for Xft's algorithm. It's like ClearType's but the filtering stage (to reduce color fringes) uses a higher-tap filter. The ClearType algorithm isn't that ground-breaking. It's largely a rehash of work that was done a long time ago. Since Xft's implementation isn't largely different, and the area is pretty well documented (beyond the rather skimply ClearType docs, and yes I have read them), there is no point in publishing it.
Slashdot Mirror
AltiVec can be pretty nice, but it's got a serious limitation. The G4's memory bandwidth is a paltry 1.3 GB/sec (shared by two processors on most PowerMacs). If you consider that a single vector takes up 16 bytes, then a single AltiVec unit can theoretically chew through 16 gigabytes of data per second. Even if you take into account the G4's L3 cache (1-2MB @ 4GB/sec) the G4 has nowhere near the bandwidth of a P4, which has 4.2 GB/sec to main memory. At that point, it doesn't matter if the AltiVec unit is ten times as fast as the P4. Unless the data fits mostly in the caches, both processors will be memory bandwidth limited. This situation favors the x86 chips, because recently, memory bandwidth has been climbing very quickly. By Q3-2003, x86 chips will hit 6.4GB/sec of main memory bandwidth.
Intel provides a nice, really easy to use C++ vector library as well. It provides C++ vector datatypes that make working with vectors the same as working with regular floats.
Doh. The typing test would be better without the spelling and grammer mistakes in the text...
As a long time KDE user, I have to say it really isn't. KDE seems much more Mac (classic Mac, not OS X) to me than anything else. The KDE-bundled applications are very non-Windows like. They tend to be simple and streamlined, rather than bloated and complex. KWord, for example, is very elegant, like WordPerfect, rather than like MS Word.
The sad thing is that a 1.25 Ghz Alpha is competitive with the new IBM 970 (a 3Ghz P4 is slightly faster, both in integer and floating point). Damn it. Just release a 1.8 Ghz Alpha on a 0.13 SOI process and take over the world. How hard can it be!
Just used it the day before yesterday (10.2.1) on a G4-800 MHz. Still bloody slow. The 2GHz P4's running Win2K next to it are much faster, and were probably cheaper... If you think OS X on a G3-400 MHz is usable, you must either be very old, or already dead.
Well, I had the same problem, and setting IgnoreEDID it fixed it for me. For reference, I was running an Athlon XP 1700 on a SiS motherboard with a GeForce2 MX. On my Inspiron 8200 with GeForce4 MX, I don't have any problem at all. So it must be something with your particular configuration.
New stuff is expensive. But new stuff makes old stuff be cheaper. Right now, a GF4 Ti 4200 can be had for just over $100. It's a great buy, and at that price, you can afford to upgrade much more often. Of course, there are people that actually do need this kind of power (the vertex and pixel shaders are amazing, just from a programming point of view) and they're willing to pay for it.
Are you using multi-head by any chance? The TwinView code seems to be kinda flaky. Also, are you running the 4191 drivers, which have some major architectural changes and are thus kinda flaky. I've been using NVIDIA's Linux drivers back before it was cool (on a TNT-1) and they've been perfectly stable.
PS> NVIDIA is in no position to open their drivers. We're not talking a NIC card driver here. An OpenGL ICD is the whole OpenGL subsystem. NVIDIA's "drivers" total about 5-6MB, and includes kernel and XFree drivers, GLX module, and GL and GLU libraries. There is a whole lot of high level stuff in there that 1) NVIDIA doesn't own all the IP to and 2) Could really help out manufacturers with sucky drivers (*cough* ATI *cough*).
Actually, that's not general crapiness in the drivers. That has to do with a very long monitor mode probing that's going on. You can relieve the problem by setting the IgnoreEDID field in XF86Config (in the NVIDIA section). That said, the 4191 is quite buggy. To be fair, they are moving to an entirely new 2D architecture (moving from XAA to their own design) so weirdness is to be expected. I just wish they had labled the drivers "beta" or something. All the other drivers (I've been using them since the first release) have been very stable, however. I recommend sticking with 3123 for the time being.
/. seems to have become the home of a bunch of pansies. "My iMac doesn't have a fan!" "The fan noise is too loud!" "My ears are bleeding!" Bah. You're all sissies. I'm an Inspiron 8200 owner. It burns my lap and punctures my eardrums with fan noise! I have to turn my 400-watt Klipschs all the way up just to hear music! And I *like* it that way! This new GPU fan isn't so bad. I've got a 7000 RPM fan on my Athlon back home, and not only can I hear the jet-turbine noise in another room, I can hear it on another floor! And I *like* it that way! So bring it on NVIDIA! It's not like I can hear the damn thing anyway!
I just played Rogue Leader this afternoon, and I can still see polygons. FFX is one of the first games in which I almost forgot that the characters are polygonal. There is no doubt, of course, that the GPUs in the XBox and GC are more powerful, but it's an acknowledged fact that the GC simply doesn't have the poly-pushing capability of the other consoles. Even Nintendo's official line is that the GC is easy to program, but still "performance competitive".
The higher your max capabilities, the better the lower ones get. Since the parent to my post said 1920x1440, there's a good chance it'll hit at least 75Hz at that resolution.
>>>>>>>>>
75 Hz is too low, and besides, even then 1920x1440 is only 120 dpi. Like I said, I have yet to see a CRT than can match the resolution and image stability of my Dell LCD.
Actually, the GC doesn't have better hardware, because it's main CPU lacks vector units. The PS2 simply has more floating point power available, there's no debating that. I've seen StarFox Adventures, and I'm really not impressed at all. It has nice special effects, but to my eyes, detailed modeling is more important at this ti
Even Metriod Prime, which has the best graphics of any GC game, has noticibly low poly models (especially the terrain). The gamecube could *not* push all the polygons in FFX. I've seen screenshots of PN:03, and they suffer from the same weakness of all gamecube games: low poly environments.
Actually, the PS2 has more VRAM than the Gamecube (4MB vs 3MB). The major problem is that the PS2's graphics chip doesn't do anti-aliasing or as many special effects. Either way, it's much less important for the PS2, which is designed to stream textures rather than cache them in VRAM. Read the ArsTechnica article for more info on the PS2 architecture. As for the color palatte, it's all 16 or 32 bit color, the PS2 doesn't accelerate palettized modes.
The problem with resolutions that high on CRTs is that it tends to make the image very grainy. I know pushing my 19" up to 1600x1200 noticibly reduces quality. I haven't seen any 19" CRTs that have a recommended resolution higher than 1280x1024. And no CRT will go to 1920x1440 with 85+ Hz, which I find is the absolute minimum for a decently stable image. I prefer mine to be 90-100 Hz, since I'm quite sensitive to flicker, but no CRT I've seen approaches the (perfect) image stability of my LCD.
I refuse to buy a monitor that doesn't have at least a 120 DPI native resolution. That rules out pretty much every CRT. I switched from a nice 19" Sony Trinitron to a 15" 1600x1200 Dell laptop LCD, and it's the best switch I've ever made. Staring at text just plain becomes easier when there are enough pixels to actually display letter shapes! The total lack of flicker and zero geometric distortion doesn't hurt!
Actually, it's less advanced than the PS2. The graphics processor has more features, but the PS2 has insane vector processing capabilities, which let's it push insane polygons. The Gamecube hardware can drive some nifty special effects, but the PS2 can make some genuinely good looking games (FF-X would not be possible on GC).
Look, I like documentation as much as the next guy. But we're talking less than two dozen lines of code here! The point your missing is that Xft isn't supposed to be the definitive reference on this (unlike the RFC). All the information is available elsewhere. All that is needed is a note saying that Xft uses a "simple intra-pixel filter" (quote from the Xft documentation) and the specific filter used. Publishing an article about the technique used in Xft would be like publishing an article about how your project uses compiler options in its build!
PS> I'm not an EE. If I was, I'd probably know what your code sample did. I am, however, pretty well versed in typography and imaging, so it was easy for me to figure out what the Xft code did. It is assumed, when dealing with code like this, that the reader has at least a basic knowledge of the problem domain.
The internet is a great place to make money. Companies that understand this, like Dell, Apple, IBM, the various online retailers, etc, are in a powerful position. I have personally spent thousands of dollars online, and now do almost all my major purchases on the internet. If music was conveniently available online, a chunk of that money would go the RIAAs way. But since it isn't, well, too bad for them.
I have no idea. You didn't give me any context, and your variable names suck. With the Xft code, however, there is a whole lot of context. You know you're applying a certain filter to the pixels of the bitmap. Applying filters is a well known technique. There are lots of digital signal processing packages out there that will do it for you. Right at the top of xftglyphs.c is a variable named "filters" that tell you exactly what filters are being applied. That's all you need to know. There is no point publishing a paper when the process is so well known to those working in the field.
That Mac people are just plain creepy...
Actually, there are no monitors out there that are high res enough to abandon hinting. My LCD is as high-res as you can get without going to Roentgen (1600x1200 - 15" = 133 dpi) and even then at least minimal hinting is required to get good looking fonts. OS X fonts (IMO) look shitty. The major problem is the color. 'Color' is typography-speak for the evenness of the weight of the strokes along the line. Hinting mechanisms make sure there is roughly an even amount of black in any given area along the line. This makes reading much smoother. Without hinting, proper color is just shot. Then there is the problem that without hinting fonts are far too fuzzy to be comfortably readable. One thing OS X fonts *do* have (and which people swoon over at demos, until they actually have to stare at them for 8 hours a day) is really good letter shape, because no hinting (read: deformation) is done for the sake of legibility. However, minimal hinting can be done to improve legibility a huge amount, without sacrificing too much from the letter shape.
Um, unlike ClearType, you can just go read the code for Xft's algorithm. It's like ClearType's but the filtering stage (to reduce color fringes) uses a higher-tap filter. The ClearType algorithm isn't that ground-breaking. It's largely a rehash of work that was done a long time ago. Since Xft's implementation isn't largely different, and the area is pretty well documented (beyond the rather skimply ClearType docs, and yes I have read them), there is no point in publishing it.