Do any of us care about the plight of other human beings that we can't directly relate to? >>>>>>> Apparently not. I've given up on the world already, and I'm only 19... Don't lose sleep over it, because the world sucks and there is nothing you can do about it:)
Most Iraqis are not Saddam. I was trying to get the sig to say "American lives are not inherently worth more than Iraqi lives" but I hit the 120 character limit. I assumed most people would be smart enough to catch on to what I meant...
If you ever take a look at the Voodoo register level specs, you'll see that it's basically Glide with registers instead of procedures. Of course, that says a whole lot about the Voodoo hardware. The hardware manual was like a "Graphics Driver Programming Tutorial" and the register interface was dead simple. Makes me nearly cry when I read an Intel reference manual and compare the two...
Re:How often do you move your monitor
on
LCD Overtaking CRT
·
· Score: 1
I can't give you a scientific study, only personal experience. After I moved to an LCD, I can stare at the screen all day without getting a headache. Before, I could look at a CRT for an hour or two, tops. I'm also really sensitive to refresh rate (I ran my previous CRT at 90Hz) and LCD's have absolutely zero flicker, even out of the corner of your eye. You have to continually refresh a CRT because the phospor starts to decay in brightness the instant the beam leaves it. If it decays too much before the next sweep, your eye notices the change in brightness and you percieve flicker. In an LCD, the backlight is at constant brightness. So even though the refresh rate is a low 60 Hz, there is no flicker. In a static image, the refresh rate could be 0 Hz and there would still be no flicker.
Not to mention the fact that a good LCD is much better for your eyes than the flickery radiation fest that even high-quality CRTs are. I used to use a high-end 19" Trinitron, and couldn't stare at the screen for more than an hour without getting a headache. I can stare at my LCD all day without getting anything more than a little bleary-eyed from not blinking.
Actually, you can get close (1600x1200) on a 15" $900 laptop panel. Of course, you'll have to rig a way to hook it to your desktop machine. Why they don't sell these panels seperately (even though they come in tons of laptops) is beyond me.
First, the American army will be killing a whole bunch of civilians in this conflict, while the Iraqi army won't (the war is nowhere near US soil). Second, I was thinking more of civilians than anybody else. Even conservative estimates put the civilian casualty in Iraq at 1000-3000. We're giving Iraq their own personal 9-11 (3005 civilian casualties).
I meant the layering of Qt on KDE on Xlib has no real effect on performance beyond what the internal layering of any maintainable design would have.
You don't seem to have a real understanding of how the layering here works. You're just throwing around lots of names and hoping to make a point. Just because lots of toolkits exist, doesn't mean they all layer on top of each other. Just because the layering in Windows is opaque* to users doesn't mean its not there. Let's look at this clearly:
KDE is *designed* to be layered on Qt, which is *designed* to be layered upon Xlib. GNOME is *designed* to be layered on GTK, which is *designed* to be layered on Xlib. These designs can be just as integrated as the layers within the Windows libraries. Of course, KDE isn't designed to layer on GTK, and it never does. Even when you're running KDE apps in GNOME, the control path still goes KDE -> Qt -> Xlib -> Xserver. (GTK and Qt) (aRts and ESD) (KDE and GNOME), each pair is a sibling, and there is no layering inbetween them. The window manager is a seperate process (not a layer) that doesn't even get involved unless you're moving or resizing a window.
As for X being the past, I contest that. XFree86 was hugely overhauled in the 4.0 release. It will be greatly improved again in the 5.0 release. The resolution switching issue is a cop-out. The 4.3 release (not CVS) has XRandR, but how often do you change resolution that you can't restart X? What important feature does Windows have that X doesn't?
Accelerated Video - Xv. Hardware OpenGL - DRI, NVGL. Antialiased fonts - FreeType (awesome quality in the 2.1.4 release!) Easy font installation - FontConfig (just drop them into/usr/share/fonts) Vector API - libart, librsvg now, Xr/Xc when it comes out.
The only thing I can think of at the moment is window transparency, which is a gimmick feature more than anything else.
I think the main thing I'm getting at is I don't want the dichtomy anymore. Graphics are graphics, so lets handle them the same way. OpenGL implementations have really gotten very advanced. The optimization is good enough that running a full screen OpenGL app in front of another full-screen OpenGL app runs at almost the same speed as just running one at a time, because no extraneous updates are performed. It would be awesome to utlize all this power without burdening my CPU, which is often pegged running compiles or something in the background.
To tell the truth, I'm no longer happy with "buttons and widgets" or mere eye candy like transparency and shadows. I'd like to see a real flashy GUI, like the one at www.xeofreestyle.com. I feel kind of stupid saying this (it's the grognard side of me arguing with the asthetic side), but current GUIs just aren't inspiring or dynamic. They're not something visually pleasing and artistic. Even stuff like OS X *looks* like a computer, and kinda looks cheesy at that. I'm convinced you can made artistic GUIs without sacrificing (heck, even enhancing) user efficiency, and I'd like to see a platform that can fully support such a GUI if it were ever developed.
Actually, an non-maskable-interrupt is a very specific thing: it's an interrupt on the CPU's NMI pin. CTRL-ALT-DELETE is just a regular old keycode, and is delivered via the maskable interrupt pin. It's just that the key-sequence is trapped in the lower levels of the system and never propogated to userspace. Microsoft could have caught another key sequence instead and had things work just the same way, but there would be the off chance that this other key sequence would've been already in use for something else.
Actually, I wouldn't desecrate my Linux system by using MS fonts. I use the Adobe TypeBasics fonts. I find them to be better suited to FreeType 2 (the pshinter has some intelligence the TT hinter without bytecode interpreter doesn't) and much better suited (thanks to their "general guideline" rather than pixel-specific hinting) to antialiased rendering on my high-res LCD. They're also a bit more elegant, IMHO, than the MS fonts.
But for many other applications of X11, they don't make much sense. That's why it is good to provide them as extensions. >>>>>>>> I agree to that. I never said it couldn't be provided as extensions.
And a simple, true-color-only unaccelerated implementation of its graphics and 2D primitives really is pretty easy and perfectly sufficient for pretty much all traditional uses of X11 (c.f. Xvnc). "Ditching" it seems to have only disadvantages as far as I can tell. >>>>>> I didn't mean we should ditch core X. I meant I see no reason you should define a new API (via an extension) like Xr/Xc, when you could implement the same functionality on top of OpenGL. That way, all accelerated GLX implementations could get support for the new vector graphics API automatically, without having to put support in their drivers for yet another graphics API.
OpenGL is not suitable for general purpose 2D raster graphics--it simply doesn't have enough well-defined bit-level semantics, and it simply cannot support a vast amount of existing X11 applications. Until we all get 300dpi screens, it really matters where each individual pixel falls, and X11 defines that. >>>>>>>>> Several programs (Shake, XSI, Blender, OpenGUI) use OpenGL to draw their UI, and the result is indistinguishable from something like Maya which uses Motif. Further, I don't really think you need pixel-level control for most things. The only place I can think of is text, but that can be represented as unscaled bitmaps. If the semantics of a vector graphics language like Quartz2D or DisplayPostscript (or Xr/Xc) can be suitable for a GUI, I see no reason why OpenGL should be any less suitable. As for not being supported on many implementations, I don't argue with you. Only modern desktop machines that need a vector graphics UI would use this. The assumption here is that machines that would have good support for Xr/Xc would also have good support for GLX. That's not a bad assumption, and it's certainly a better one than the reverse.
That's actually spelled "typo". >>>>>>>>>> The original poster used "Quarts" twice or thrice.
I've been thinking of this for awhile. We need a abstract representation of class templates. This would not only make it easier to factor out identical instances, but it would allow for runtime code generation, meaning that you could distribute "real" template libraries where users could instantiate templates with their own types.
I think the "she" usage if fine. Males have been favored in our culture for decades and still are. One extra letter, giving women a little nod indicating that things are changing is the least we can do.
It's pretty easy to understand templates without using a book. The actual template mechanism is extremely compact. Fully exploiting the power of templates requires a book. This is the same reason so many books on OO design exist.
A) Calling VS 2003 "THE MOST standards complient" is bullshit until it's actually released. I hear its good, but better than GCC or Intel C++ 7.x? The community will decide that, not Microsoft's marketing department. B) The 'export' keyword is not useless just because VS 2003 doesn't support it. It's certainly rather limited in its usefulness, and I've only really wanted it a couple of times, but it's not useless. C) Comeau uses the platform's native C compiler to actually generate code. It can use gcc (very good code generation in the 3.2.x series), or Visual C++ 7.0 and a number of others).
G++ isn't 100% standards complient, but it's pretty damn good. It compiles almost all of Boost. That's more than can be said of Visual C++ 6 or 7. 7.1 is supposed to be better, but IIRC, it's still in beta.
Actually, there is one key thing that templates can do that nothing in C can: code generation. Templates can allow you to generate type-safe, generic classes (particularly data structures) well-optimized to the actual data type they contain. Aside from hand coding multiple implementations for different data types, or losing type-saftey by using void pointers, you just can't do this in C. Ditto for stuff like design patterns implemented as templates or a number of other powerful techniques. Read Modern C++ and take a look at some of the modern C++ websites (especially Boost).
You're thinking of this. I haven't used them myself, but then again, GCC 3.2.x's STL error messages are generally quite good. Not EDG quality, but pretty good. Certainly not as bad as the Visual Studio 6 crap that seems to have scared many people away from advanced C++.
First, Quarts = Quartz. Second, there is no reason for X to be faster than GDI, architecturally. I don't know too much about Quartz's internals, but there are two things that could be the case:
a) It's slower because the internal architecture relies to heavily on PDF to allow 2D drawing to happen via OpenGL. This seems to be the case at the moment (Quartz Extreme, as you said, just accelerates compositing, not actual drawing). b) It's much faster because it's vector-oriented API allows it to ditch a PDF representation internally and use OpenGL to accelerate all drawing. Depending on the details of Apple's implementation, this case is certainly possible within the constraints of Quartz's architecture.
Definately, vector based graphics are the way to go. KeithP and friends are working right now on an Xr/Xc API that will allow X apps to use server-side vector graphics. In my opinion (and this is a point of contention on the mailing lists) the best way to go would be to ditch the idea of an X-specific API, and just make a library on top of OpenGL that provides a simple 2D subset. Then, they'd get acceleration for free without requiring driver developers to support yet another API. They got lucky that vendors like NVIDIA decided to support XRender in hardware, but a accelerated 2D vector graphics API will require use of the 3D hardware and make it rather complex for driver writers to implement.
It doesn't change the fact that all of X's various hacked on "extensions" just to make it usable are slowing everything down, from stacks of window library layers to conflicting interfaces to the fact that KDE and GNOME are just plain awful as desktop environments compared to OS X and Windows XP. >>>> Wow. All one sentence! Praytell, how do extensions slow things down? You render via Core X, or via Xft. They're not layered. And the layering you see is present in any desktop architecture (it's good program design!), it's just more visible in X. Let's take a look at some relationships:
Now, the layering of the two architectures is almost the same. Some points need to be clarified: *1) It's more accurate to consider the core protocol (libX11) and extensions (libXft) as having a sibling relationship. *2) The KDE libs are indeed layered on the Qt libs. However, I'll bet you a whole lot of money that all the DLLs that implement the Win32 toolkit have an internal layering. In particular, more modern stuff like Win.Forms and MFC are probably layered on top of classic Win32 abstractions. *3) Yes, the window manager is the only difference. The window server in X is a seperate process, while the window server in Windows is built into the GDI.
Layering has no real effect on performance. Take, for example, the seperate window manager. It's doesn't get involved at all unless a window moves. It's not like the drawing calls from an app have to go through the window manager first. Either way, the internal layering within libraries plays a far larger role in creating an abstraction performance penalty. However, that's just the realities of software engineering.
Slashdot Mirror
Do any of us care about the plight of other human beings that we can't directly relate to? :)
>>>>>>>
Apparently not. I've given up on the world already, and I'm only 19... Don't lose sleep over it, because the world sucks and there is nothing you can do about it
Most Iraqis are not Saddam. I was trying to get the sig to say "American lives are not inherently worth more than Iraqi lives" but I hit the 120 character limit. I assumed most people would be smart enough to catch on to what I meant...
This says that AMD might make (manufacture) PowerPC chips. So maybe CmdrTaco isn't asleep after all.
If you ever take a look at the Voodoo register level specs, you'll see that it's basically Glide with registers instead of procedures. Of course, that says a whole lot about the Voodoo hardware. The hardware manual was like a "Graphics Driver Programming Tutorial" and the register interface was dead simple. Makes me nearly cry when I read an Intel reference manual and compare the two...
I can't give you a scientific study, only personal experience. After I moved to an LCD, I can stare at the screen all day without getting a headache. Before, I could look at a CRT for an hour or two, tops. I'm also really sensitive to refresh rate (I ran my previous CRT at 90Hz) and LCD's have absolutely zero flicker, even out of the corner of your eye. You have to continually refresh a CRT because the phospor starts to decay in brightness the instant the beam leaves it. If it decays too much before the next sweep, your eye notices the change in brightness and you percieve flicker. In an LCD, the backlight is at constant brightness. So even though the refresh rate is a low 60 Hz, there is no flicker. In a static image, the refresh rate could be 0 Hz and there would still be no flicker.
Not to mention the fact that a good LCD is much better for your eyes than the flickery radiation fest that even high-quality CRTs are. I used to use a high-end 19" Trinitron, and couldn't stare at the screen for more than an hour without getting a headache. I can stare at my LCD all day without getting anything more than a little bleary-eyed from not blinking.
Actually, you can get close (1600x1200) on a 15" $900 laptop panel. Of course, you'll have to rig a way to hook it to your desktop machine. Why they don't sell these panels seperately (even though they come in tons of laptops) is beyond me.
First, the American army will be killing a whole bunch of civilians in this conflict, while the Iraqi army won't (the war is nowhere near US soil). Second, I was thinking more of civilians than anybody else. Even conservative estimates put the civilian casualty in Iraq at 1000-3000. We're giving Iraq their own personal 9-11 (3005 civilian casualties).
I meant the layering of Qt on KDE on Xlib has no real effect on performance beyond what the internal layering of any maintainable design would have.
/usr/share/fonts)
You don't seem to have a real understanding of how the layering here works. You're just throwing around lots of names and hoping to make a point. Just because lots of toolkits exist, doesn't mean they all layer on top of each other. Just because the layering in Windows is opaque* to users doesn't mean its not there. Let's look at this clearly:
KDE is *designed* to be layered on Qt, which is *designed* to be layered upon Xlib. GNOME is *designed* to be layered on GTK, which is *designed* to be layered on Xlib. These designs can be just as integrated as the layers within the Windows libraries. Of course, KDE isn't designed to layer on GTK, and it never does. Even when you're running KDE apps in GNOME, the control path still goes KDE -> Qt -> Xlib -> Xserver. (GTK and Qt) (aRts and ESD) (KDE and GNOME), each pair is a sibling, and there is no layering inbetween them. The window manager is a seperate process (not a layer) that doesn't even get involved unless you're moving or resizing a window.
As for X being the past, I contest that. XFree86 was hugely overhauled in the 4.0 release. It will be greatly improved again in the 5.0 release. The resolution switching issue is a cop-out. The 4.3 release (not CVS) has XRandR, but how often do you change resolution that you can't restart X? What important feature does Windows have that X doesn't?
Accelerated Video - Xv.
Hardware OpenGL - DRI, NVGL.
Antialiased fonts - FreeType (awesome quality in the 2.1.4 release!)
Easy font installation - FontConfig (just drop them into
Vector API - libart, librsvg now, Xr/Xc when it comes out.
The only thing I can think of at the moment is window transparency, which is a gimmick feature more than anything else.
You can walk to your local CompUSA or order online.
I think the main thing I'm getting at is I don't want the dichtomy anymore. Graphics are graphics, so lets handle them the same way. OpenGL implementations have really gotten very advanced. The optimization is good enough that running a full screen OpenGL app in front of another full-screen OpenGL app runs at almost the same speed as just running one at a time, because no extraneous updates are performed. It would be awesome to utlize all this power without burdening my CPU, which is often pegged running compiles or something in the background.
To tell the truth, I'm no longer happy with "buttons and widgets" or mere eye candy like transparency and shadows. I'd like to see a real flashy GUI, like the one at www.xeofreestyle.com. I feel kind of stupid saying this (it's the grognard side of me arguing with the asthetic side), but current GUIs just aren't inspiring or dynamic. They're not something visually pleasing and artistic. Even stuff like OS X *looks* like a computer, and kinda looks cheesy at that. I'm convinced you can made artistic GUIs without sacrificing (heck, even enhancing) user efficiency, and I'd like to see a platform that can fully support such a GUI if it were ever developed.
Actually, an non-maskable-interrupt is a very specific thing: it's an interrupt on the CPU's NMI pin. CTRL-ALT-DELETE is just a regular old keycode, and is delivered via the maskable interrupt pin. It's just that the key-sequence is trapped in the lower levels of the system and never propogated to userspace. Microsoft could have caught another key sequence instead and had things work just the same way, but there would be the off chance that this other key sequence would've been already in use for something else.
Actually, I wouldn't desecrate my Linux system by using MS fonts. I use the Adobe TypeBasics fonts. I find them to be better suited to FreeType 2 (the pshinter has some intelligence the TT hinter without bytecode interpreter doesn't) and much better suited (thanks to their "general guideline" rather than pixel-specific hinting) to antialiased rendering on my high-res LCD. They're also a bit more elegant, IMHO, than the MS fonts.
But for many other applications of X11, they don't make much sense. That's why it is good to provide them as extensions.
>>>>>>>>
I agree to that. I never said it couldn't be provided as extensions.
And a simple, true-color-only unaccelerated implementation of its graphics and 2D primitives really is pretty easy and perfectly sufficient for pretty much all traditional uses of X11 (c.f. Xvnc). "Ditching" it seems to have only disadvantages as far as I can tell.
>>>>>>
I didn't mean we should ditch core X. I meant I see no reason you should define a new API (via an extension) like Xr/Xc, when you could implement the same functionality on top of OpenGL. That way, all accelerated GLX implementations could get support for the new vector graphics API automatically, without having to put support in their drivers for yet another graphics API.
OpenGL is not suitable for general purpose 2D raster graphics--it simply doesn't have enough well-defined bit-level semantics, and it simply cannot support a vast amount of existing X11 applications. Until we all get 300dpi screens, it really matters where each individual pixel falls, and X11 defines that.
>>>>>>>>>
Several programs (Shake, XSI, Blender, OpenGUI) use OpenGL to draw their UI, and the result is indistinguishable from something like Maya which uses Motif. Further, I don't really think you need pixel-level control for most things. The only place I can think of is text, but that can be represented as unscaled bitmaps. If the semantics of a vector graphics language like Quartz2D or DisplayPostscript (or Xr/Xc) can be suitable for a GUI, I see no reason why OpenGL should be any less suitable. As for not being supported on many implementations, I don't argue with you. Only modern desktop machines that need a vector graphics UI would use this. The assumption here is that machines that would have good support for Xr/Xc would also have good support for GLX. That's not a bad assumption, and it's certainly a better one than the reverse.
That's actually spelled "typo".
>>>>>>>>>>
The original poster used "Quarts" twice or thrice.
I've been thinking of this for awhile. We need a abstract representation of class templates. This would not only make it easier to factor out identical instances, but it would allow for runtime code generation, meaning that you could distribute "real" template libraries where users could instantiate templates with their own types.
I think the "she" usage if fine. Males have been favored in our culture for decades and still are. One extra letter, giving women a little nod indicating that things are changing is the least we can do.
::digs book out from under chair::
Perhaps *you* meant Andrei?
It's pretty easy to understand templates without using a book. The actual template mechanism is extremely compact. Fully exploiting the power of templates requires a book. This is the same reason so many books on OO design exist.
Ha ha. Silly MS programmers with their Visual C++ 6.x. Either spend the money and upgrade to 7.0, or be a real man and use GCC.
A) Calling VS 2003 "THE MOST standards complient" is bullshit until it's actually released. I hear its good, but better than GCC or Intel C++ 7.x? The community will decide that, not Microsoft's marketing department.
B) The 'export' keyword is not useless just because VS 2003 doesn't support it. It's certainly rather limited in its usefulness, and I've only really wanted it a couple of times, but it's not useless.
C) Comeau uses the platform's native C compiler to actually generate code. It can use gcc (very good code generation in the 3.2.x series), or Visual C++ 7.0 and a number of others).
G++ isn't 100% standards complient, but it's pretty damn good. It compiles almost all of Boost. That's more than can be said of Visual C++ 6 or 7. 7.1 is supposed to be better, but IIRC, it's still in beta.
Actually, there is one key thing that templates can do that nothing in C can: code generation. Templates can allow you to generate type-safe, generic classes (particularly data structures) well-optimized to the actual data type they contain. Aside from hand coding multiple implementations for different data types, or losing type-saftey by using void pointers, you just can't do this in C. Ditto for stuff like design patterns implemented as templates or a number of other powerful techniques. Read Modern C++ and take a look at some of the modern C++ websites (especially Boost).
You're thinking of this.
I haven't used them myself, but then again, GCC 3.2.x's STL error messages are generally quite good. Not EDG quality, but pretty good. Certainly not as bad as the Visual Studio 6 crap that seems to have scared many people away from advanced C++.
First, Quarts = Quartz. Second, there is no reason for X to be faster than GDI, architecturally. I don't know too much about Quartz's internals, but there are two things that could be the case:
a) It's slower because the internal architecture relies to heavily on PDF to allow 2D drawing to happen via OpenGL. This seems to be the case at the moment (Quartz Extreme, as you said, just accelerates compositing, not actual drawing).
b) It's much faster because it's vector-oriented API allows it to ditch a PDF representation internally and use OpenGL to accelerate all drawing. Depending on the details of Apple's implementation, this case is certainly possible within the constraints of Quartz's architecture.
Definately, vector based graphics are the way to go. KeithP and friends are working right now on an Xr/Xc API that will allow X apps to use server-side vector graphics. In my opinion (and this is a point of contention on the mailing lists) the best way to go would be to ditch the idea of an X-specific API, and just make a library on top of OpenGL that provides a simple 2D subset. Then, they'd get acceleration for free without requiring driver developers to support yet another API. They got lucky that vendors like NVIDIA decided to support XRender in hardware, but a accelerated 2D vector graphics API will require use of the 3D hardware and make it rather complex for driver writers to implement.
It doesn't change the fact that all of X's various hacked on "extensions" just to make it usable are slowing everything down, from stacks of window library layers to conflicting interfaces to the fact that KDE and GNOME are just plain awful as desktop environments compared to OS X and Windows XP.
>>>>
Wow. All one sentence! Praytell, how do extensions slow things down? You render via Core X, or via Xft. They're not layered. And the layering you see is present in any desktop architecture (it's good program design!), it's just more visible in X. Let's take a look at some relationships:
X + drivers -> GDI + drivers
X11 socket protocol -> GDI syscall protocol
libX11.so -> gdi32.dll (and others)
libXft.so -> gdi32.dll (*1)
Qt libs -> user32.dll, commctl.dll, comdlg32.dll, mfc.dll
KDE libs -> same as above (*2)
window manager -> built-into GDI. (*3)
Now, the layering of the two architectures is almost the same. Some points need to be clarified:
*1) It's more accurate to consider the core protocol (libX11) and extensions (libXft) as having a sibling relationship.
*2) The KDE libs are indeed layered on the Qt libs. However, I'll bet you a whole lot of money that all the DLLs that implement the Win32 toolkit have an internal layering. In particular, more modern stuff like Win.Forms and MFC are probably layered on top of classic Win32 abstractions.
*3) Yes, the window manager is the only difference. The window server in X is a seperate process, while the window server in Windows is built into the GDI.
Layering has no real effect on performance. Take, for example, the seperate window manager. It's doesn't get involved at all unless a window moves. It's not like the drawing calls from an app have to go through the window manager first. Either way, the internal layering within libraries plays a far larger role in creating an abstraction performance penalty. However, that's just the realities of software engineering.