Re:Getting higher speeds out of Linux graphics
on
Fresco M1 Released
·
· Score: 2
The MITSHM documentation [reptiles.org] was written by Jonathan Corbet (of Linux Weekly News?) and Keith Packard in 1991. That's over 11 years ago! Is there a lack of good documentation because people are really too busy to write the documentation or is it because they do not want to write documentation?
Well, MITSHM is over 11 years old and there's little value in writing new instructions for MITSHM because there's nothing new to add. Some of the newer extensions have good documentation (eg, XRender).
But whether individual developers don't write documentation because they don't have time or simply don't want to is something I can't answer. I daresay it's a bit of both.
Re:Getting higher speeds out of Linux graphics
on
Fresco M1 Released
·
· Score: 2
But where's good documentation for DGA? Is there anything faster than DGA in X?
Depends on what you're doing. DGA gives you direct access to the framebuffer. This means you miss out on potential hardware speedups (line renderers, rectangle fillers, bit blitters, etc) which are increasingly common in modern GPUs. But if you just want to flip bits in the framebuffer then DGA is as good as it gets.
Other extensions that might help you improve the speed of your application - dependant on what you're doing, of course - include XVideo, XRender and DRI. The DRI has the greatest potential (no queue, no encoding, no decoding, no buffer copying, no context switch) but DRI has only been implemented for GLX so far.
The documentation problem you mention is very real. Part of the problem is that very few people know the extensions well enough to document them. Those people who do know the extensions well are VERY busy improving XFree. However, if you know about MIT-SHM, DGA, XVideo, XRender and DRI then you know all of the relevant extensions already.
Re:You know, Fresco...doesn't ring a bell?
on
Fresco M1 Released
·
· Score: 2
Luckily this has changed since HP and SGI have both donated code and X came out with dri for much better performance.
HP and SGI did not contribute to the DRI.
Without dri even the fastest of machines redrew graphics commands at a slugish rate.
The DRI is only used for GLX. Maybe this will change in the future, but Xlib operations today still use the old indirect rendering model.
As someone who did PC support for years, I can relate to this. Everyone and their brother wants help with their PC's, and expects it for free. They think you like nothing better than to sit around giving computer advice at family functions, parties, etc. You wouldn't expect your brother-in-law the mechanic to fix your car for free, would you?
Well... yes. I would. And he would. Because that's what family is all about.
If I use any gpl'ed code in my software, I HAVE to distribute the sources with the binaries.
No, you don't. There's no law which says that.
The GPL basically says "we won't sue you for copyright infringement IF you release the source code and give the next guy the same rights we gave you". If you choose to pass on that good offer then you can be sued for copyright infringement - and you'll almost certainly lose - but subsequent distribution of source code is for the judge to decide. The judge might decide upon punitive damages instead. Or the two parties might settle out of court: "take the code out and I won't sue" or "pay me money and I won't sue".
Everybody so far has decided to take the easy option and release their stuff as GPL rather than risk it in the courts. But the GPL is not binding if you don't accept it. Of course, you'd be damn stupid not to accept it, because the default copyright is far worse and opens you up to being sued.
Teaching a secretary how to download, configure, and compile the latest version of OpenOffice via a command line interface would probably take a good 3 or 4 weeks (months?) of training.
That's a goddamn stupid analogy. Do you train your secretaries to install Service Packs? Add users and reset passwords with User Administrator? Configure your Active Directory domain controllers with replication and redundancy?
I wouldn't expect the damn secretary to figure anything out in the Windows world, yet you'd expect secretaries using Linux to become C programmers. How about you argue honestly instead of acting like some kind of anti-Linux bigot.
It was made by millions of spiders and was thick enough to hold coins. It wasn't sticky for catching insects. It's not known why the spiders did it.
The spiders aren't trying to catch insects anymore. They're trying to catch entymologists. Far more meat on a 40 year old scientist than a 2 month old beetle.
Finally, two questions to ask yourself as to whether MS is or is not a monopoly. First is competition. Is there more or less competition now than there was in 1995 for mainstreams OS's? Thats an easy one. Second, ask what would happen to MS's market share if they raised prices very high? Also easy.
There's only one question you need to ask yourself: was Microsoft found to be a monopoly by a Federal judge with that finding upheld in the Supreme court? The answer is YES.
Perhaps you do, but if you can't be bothered to say it clearly and politely then why should I waste my time reading it? As it is, I've got no idea what your "stand" is because all I read was a bunch of insults.
How about you state your argument without the insults and we'll go from there. I'm interested in arguing about X11 but I'm not interested in childish name-calling and emotional attacks.
The thing, as I see it, is that the GUI abstractions laid down by the use of the X protocol (if you use X you must work around its protocol for obvious resions) are, in some sense, 'in the wrong place' for the construction of modern GUI systems.
This is an interesting argument. Can you offer an example? I'd certainly agree that some X11 features were abstracted poorly. I would also agree that certain X11 features should never have been part of X11. But I'm having difficulty thinking of any problem with X11 that can't be solved with an extension. Some of these extensions might be difficult to write, but I'm optimistic given the number of excellent and timely extensions to XFree86 in just the past 5 years. Consider...
X11 predicted multiple heads but didn't predict video walls. Solved with Xinerama.
X11 didn't predict hardware video scaling. Solved with XVideo.
X11 didn't predict hardware alpha blending. Solved with XRender.
X11 didn't support direct rendering (fundamental requirement for high-speed 3D). Solved with DRI.
X11 predicted different form factors but didn't predict dynamic form factors. Solved with XRandR.
X11 didn't offer complex 2D graphic operations while DPS did. Solved with the DPS extension.
X11 didn't offer TrueType font rendering. Solved with XTT.
Do you see why I'm optimistic? Features have never been - and I will boldly claim will never be - a problem for X11. Features are added quickly and relatively painlessly by extensions. The features are integrated into modern desktop GUIs within a year or two. This isn't rhetoric or hope... it's established fact from watching KDE and GNOME.
So the only problem with X11 that would worry me is something so fundamentally broken, so fundamentally unalterable, and so fundamentally ingrained in everything about X11, that fixing it would involve a complete replacement of X11 with something entirely new. I can think of dozens of niggling problems but not a single fundamental problem.
If you'd care to rewrite your response without the condescending attitude then I'll bother to respond to it, because I'm not going to wade through your insults to find your arguments.
I don't know. Nor do I care. I made the point that other platforms are not immune to the "too many ways of doing things" disease. I really don't want to go off on an irrelevant argument about the popularity of the example I gave.
you're misunderstanding the scope of X11
The (limited) scope of X11 is the problem.
The (limited) scope of X11 is why X11 still exists. If X11 had tried to dictate appearance and behaviour and colour schemes and graphics formats - the level of detail that you would seem to like from X11 or its successor - then it would have been a dead project within 18 months.
Let me expand on this point. There have been 100s of competing GUIs from 100s of vendors. All incompatible. All aimed at different form factors with different design goals. All very different in terms of user interfaces and programming interfaces. But most of them share one thing in common... nobody uses them anymore. What people wanted from GUIs changed quickly and many of the "bare to the metal" GUIs couldn't evolve fast enough.
X11 wisely chose not to dictate the form factor, or the user interface, or the programming interface. X11 provides you with the tools so you can build your GUI without having to write all the boring low-level stuff such as video drivers, event handlers, windowing operations, etc. You can simply concentrate on the GUI. So while GUIs change from year to year, there has never been a good reason to get rid of X11, because X11 IS NOT A GUI.
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Since PicoGui is not a widget set, one way to approach that problem is to write all widget-sets as PicoGui themes.
And as I said before, you've got no chance of that ever happening, so stop wishing for it. You might as well wish that everybody only wrote for KDE, or only wrote for CDE, or only wrote for GNOME. It's a waste of time wishing for the impossible. The proper solution comes from standards like ICCWM and XDND. No problems will be solved by throwing away X11 and hoping that everybody standardises on your favored project (ie, PicoGUI).
Back to your point. You mention that for Apple's Aqua and Microsoft's GUI there are corresponding lower level APIs: DPS and GDI respectively.
I've got no idea what Aqua uses, but it's probably not DPS. I mentioned GDI and DPS because they are comparative tools for building windowing systems.
There isn't one. Or there's much more than one (Xt, Athena, Motif, Qt, Gtk, XUL, Fltk, WxWindows, TK...).
Other systems also have more than one. I don't know MacOS but on Windows you've got OWL and MFC for starters. They look and behave completely differently, and the users easily spot the difference.
How do you resize a window in Microsoft Windows? The answer is straightforward. How do you close a program in MacOS X? Another simple answer.
Neither of those operations is defined for X.
The first one is XResizeWindow(3X).
The second one is XDestroyWindow(3X).
If you're talking about the visual elements that the user clicks upon, then you're misunderstanding the scope of X11. You might as well argue that glibc must define the layout of your configuration files.
It's true that the competitor to PicoGui isn't X, but higher-level protocols. However the headline "An X Alternative" is not incorrect. Someday X's position as the premire "Unix GUI Application Development Platform" will be supplanted by something like Gtk, Fresco, or PicoGui.
I don't disagree with the point you're inexpertly trying to make, but you're doing a terrible job. You could argue that X11 needs to be supplanted by DPS, or by Berlin, or by whatever. But you can't argue that X11 needs to be supplanted by GTK. That is like saying UNIX needs to be supplanted by Bash, or NT needs to be supplanted by Word. It's nonsensical.
And before you think I've not understood your point of view: what you want to say is that application programmers should never write directly to X, but instead should write to a single higher-level widget set (be it PicoGUI, or GTK, or Fresco). I'm going to tell you flat-out this will never happen. You aren't ever going to have a single higher-level widget set. It's not the fault of X11 either: it's this nasty thing called Freedom Of Choice.
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6.
Suppose you pick a non-biassed example and choose Microsoft GDI, Display Postscript, and X11R6. Comparing a high-level GUI toolkit to a low-level windowing system is an ineffective way to prove your point.
Not quite... it's been 15 years since X moved from X10 to X11.
I meant the last major release of X11 which was X11R6.4 (Release 6.4) in 1998. But in hindsight the changes from OpenGL 1.2 to OpenGL 2.0 will be as huge as the changes from X10 to X11, so what you said has a lot of merit.
Either way, we both prefer extensibility to vendor tyranny. Extensibility lets the market decide the success or failure of new extensions. Vendor tyranny is a "we know what's best for you" approach. Unfortunately the tyrant quite often does not know best.
You need
to realize the OpenGL isn't an open source project.
OpenGL isn't, but Mesa is, and the APIs are similar enough to be indistinguishable.
The last big improvement to OpenGL was released in 1998, version 1.2.
The last big OpenGL extension was just this year... thanks nVidia.
OpenGL was designed to be extensible. Contrast this with Direct3D where every new feature requires a completely new release. X11 was also designed to be extensible and as a result we have XRender, XRandR, XInput and XVideo, despite no major X11 release in... is it 4 years now?
OpenGL 2.0 requires changes which can't be achieved with an extension. It's exciting stuff and I'm looking forward to it. But it's incorrect for you to claim that OpenGL cannot adapt quickly. OpenGL can adapt very quickly. Any vendor can release an extension at any time and the community can use it immediately.
This means every vendor is on a level playing field - all the vendors have the same power to submit extensions - which is in opposing contrast with Direct3D where only Microsoft is allowed to play. Sure, the extension might not become part of the "standard" for several years, but if you support Direct3D then you don't mind having vendor-dictated APIs, so you should have no complaints.
What you want to do is receive that value without paying for it. You want to consume, without compensating the producer. That my friend is stealing.
This is a silly definition of stealing. It manages to cover gifts, charity, lotteries, etc. If you're going to play silly word games to win the argument then there's no point arguing with you.
No thanks to Apple for being a royal pain in the butt when it comes to their video format.
It's not Apple's fault. Apple has been very open with their QuickTime format, to the extent that it's one of the best supported AV transports in Linux. The big hint about who's to blame for problems playing any QuickTime movie encoded with the Sorenson codec is hidden somewhere in the name of the codec.
And the thief robbing a bank means the police can investigate an exciting crime instead of writing traffic tickets, makes for interesting news in the local newspapers, invigorates the local economy, and inspires improvements to security all around. In fact, the thief should be congratulated rather than arrested and sentenced!
This philosophy might work in science-fiction books but your name isn't the Stainless Steel Rat.
Slashdot Mirror
Well, MITSHM is over 11 years old and there's little value in writing new instructions for MITSHM because there's nothing new to add. Some of the newer extensions have good documentation (eg, XRender).
But whether individual developers don't write documentation because they don't have time or simply don't want to is something I can't answer. I daresay it's a bit of both.
Depends on what you're doing. DGA gives you direct access to the framebuffer. This means you miss out on potential hardware speedups (line renderers, rectangle fillers, bit blitters, etc) which are increasingly common in modern GPUs. But if you just want to flip bits in the framebuffer then DGA is as good as it gets.
Other extensions that might help you improve the speed of your application - dependant on what you're doing, of course - include XVideo, XRender and DRI. The DRI has the greatest potential (no queue, no encoding, no decoding, no buffer copying, no context switch) but DRI has only been implemented for GLX so far.
The documentation problem you mention is very real. Part of the problem is that very few people know the extensions well enough to document them. Those people who do know the extensions well are VERY busy improving XFree. However, if you know about MIT-SHM, DGA, XVideo, XRender and DRI then you know all of the relevant extensions already.
HP and SGI did not contribute to the DRI.
The DRI is only used for GLX. Maybe this will change in the future, but Xlib operations today still use the old indirect rendering model.
1) Microsoft didn't do it. They copied it off other companies.
2) There are new GUIs (Palm, Nokia) and they are definitely successful.
3) I would argue that the Internet/Web-Browsing interface was a new GUI, and it was also successful.
Well... yes. I would. And he would. Because that's what family is all about.
I pity anybody who doesn't understand this.
No, you don't. There's no law which says that.
The GPL basically says "we won't sue you for copyright infringement IF you release the source code and give the next guy the same rights we gave you". If you choose to pass on that good offer then you can be sued for copyright infringement - and you'll almost certainly lose - but subsequent distribution of source code is for the judge to decide. The judge might decide upon punitive damages instead. Or the two parties might settle out of court: "take the code out and I won't sue" or "pay me money and I won't sue".
Everybody so far has decided to take the easy option and release their stuff as GPL rather than risk it in the courts. But the GPL is not binding if you don't accept it. Of course, you'd be damn stupid not to accept it, because the default copyright is far worse and opens you up to being sued.
That's a goddamn stupid analogy. Do you train your secretaries to install Service Packs? Add users and reset passwords with User Administrator? Configure your Active Directory domain controllers with replication and redundancy?
I wouldn't expect the damn secretary to figure anything out in the Windows world, yet you'd expect secretaries using Linux to become C programmers. How about you argue honestly instead of acting like some kind of anti-Linux bigot.
The spiders aren't trying to catch insects anymore. They're trying to catch entymologists. Far more meat on a 40 year old scientist than a 2 month old beetle.
I'm not /. you fucking retard.
I hope you realise he won't get the joke.
There's only one question you need to ask yourself: was Microsoft found to be a monopoly by a Federal judge with that finding upheld in the Supreme court? The answer is YES.
Perhaps you do, but if you can't be bothered to say it clearly and politely then why should I waste my time reading it? As it is, I've got no idea what your "stand" is because all I read was a bunch of insults.
How about you state your argument without the insults and we'll go from there. I'm interested in arguing about X11 but I'm not interested in childish name-calling and emotional attacks.
You missed the bit before which was...
Which was clearly wrong, and I disproved it with an example.
If you read things out of context then they often don't make sense. Much like if I selectively quote you like this...
This is an interesting argument. Can you offer an example? I'd certainly agree that some X11 features were abstracted poorly. I would also agree that certain X11 features should never have been part of X11. But I'm having difficulty thinking of any problem with X11 that can't be solved with an extension. Some of these extensions might be difficult to write, but I'm optimistic given the number of excellent and timely extensions to XFree86 in just the past 5 years. Consider...
Do you see why I'm optimistic? Features have never been - and I will boldly claim will never be - a problem for X11. Features are added quickly and relatively painlessly by extensions. The features are integrated into modern desktop GUIs within a year or two. This isn't rhetoric or hope... it's established fact from watching KDE and GNOME.
So the only problem with X11 that would worry me is something so fundamentally broken, so fundamentally unalterable, and so fundamentally ingrained in everything about X11, that fixing it would involve a complete replacement of X11 with something entirely new. I can think of dozens of niggling problems but not a single fundamental problem.
If you'd care to rewrite your response without the condescending attitude then I'll bother to respond to it, because I'm not going to wade through your insults to find your arguments.
I don't know. Nor do I care. I made the point that other platforms are not immune to the "too many ways of doing things" disease. I really don't want to go off on an irrelevant argument about the popularity of the example I gave.
The (limited) scope of X11 is why X11 still exists. If X11 had tried to dictate appearance and behaviour and colour schemes and graphics formats - the level of detail that you would seem to like from X11 or its successor - then it would have been a dead project within 18 months.
Let me expand on this point. There have been 100s of competing GUIs from 100s of vendors. All incompatible. All aimed at different form factors with different design goals. All very different in terms of user interfaces and programming interfaces. But most of them share one thing in common... nobody uses them anymore. What people wanted from GUIs changed quickly and many of the "bare to the metal" GUIs couldn't evolve fast enough.
X11 wisely chose not to dictate the form factor, or the user interface, or the programming interface. X11 provides you with the tools so you can build your GUI without having to write all the boring low-level stuff such as video drivers, event handlers, windowing operations, etc. You can simply concentrate on the GUI. So while GUIs change from year to year, there has never been a good reason to get rid of X11, because X11 IS NOT A GUI.
And as I said before, you've got no chance of that ever happening, so stop wishing for it. You might as well wish that everybody only wrote for KDE, or only wrote for CDE, or only wrote for GNOME. It's a waste of time wishing for the impossible. The proper solution comes from standards like ICCWM and XDND. No problems will be solved by throwing away X11 and hoping that everybody standardises on your favored project (ie, PicoGUI).
I've got no idea what Aqua uses, but it's probably not DPS. I mentioned GDI and DPS because they are comparative tools for building windowing systems.
Other systems also have more than one. I don't know MacOS but on Windows you've got OWL and MFC for starters. They look and behave completely differently, and the users easily spot the difference.
The first one is XResizeWindow(3X).
The second one is XDestroyWindow(3X).
If you're talking about the visual elements that the user clicks upon, then you're misunderstanding the scope of X11. You might as well argue that glibc must define the layout of your configuration files.
I don't disagree with the point you're inexpertly trying to make, but you're doing a terrible job. You could argue that X11 needs to be supplanted by DPS, or by Berlin, or by whatever. But you can't argue that X11 needs to be supplanted by GTK. That is like saying UNIX needs to be supplanted by Bash, or NT needs to be supplanted by Word. It's nonsensical.
And before you think I've not understood your point of view: what you want to say is that application programmers should never write directly to X, but instead should write to a single higher-level widget set (be it PicoGUI, or GTK, or Fresco). I'm going to tell you flat-out this will never happen. You aren't ever going to have a single higher-level widget set. It's not the fault of X11 either: it's this nasty thing called Freedom Of Choice.
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Suppose you pick a non-biassed example and choose Microsoft GDI, Display Postscript, and X11R6. Comparing a high-level GUI toolkit to a low-level windowing system is an ineffective way to prove your point.
I meant the last major release of X11 which was X11R6.4 (Release 6.4) in 1998. But in hindsight the changes from OpenGL 1.2 to OpenGL 2.0 will be as huge as the changes from X10 to X11, so what you said has a lot of merit.
Either way, we both prefer extensibility to vendor tyranny. Extensibility lets the market decide the success or failure of new extensions. Vendor tyranny is a "we know what's best for you" approach. Unfortunately the tyrant quite often does not know best.
OpenGL isn't, but Mesa is, and the APIs are similar enough to be indistinguishable.
The last big OpenGL extension was just this year... thanks nVidia.
OpenGL was designed to be extensible. Contrast this with Direct3D where every new feature requires a completely new release. X11 was also designed to be extensible and as a result we have XRender, XRandR, XInput and XVideo, despite no major X11 release in ... is it 4 years now?
OpenGL 2.0 requires changes which can't be achieved with an extension. It's exciting stuff and I'm looking forward to it. But it's incorrect for you to claim that OpenGL cannot adapt quickly. OpenGL can adapt very quickly. Any vendor can release an extension at any time and the community can use it immediately.
This means every vendor is on a level playing field - all the vendors have the same power to submit extensions - which is in opposing contrast with Direct3D where only Microsoft is allowed to play. Sure, the extension might not become part of the "standard" for several years, but if you support Direct3D then you don't mind having vendor-dictated APIs, so you should have no complaints.
This is a silly definition of stealing. It manages to cover gifts, charity, lotteries, etc. If you're going to play silly word games to win the argument then there's no point arguing with you.
It's not Apple's fault. Apple has been very open with their QuickTime format, to the extent that it's one of the best supported AV transports in Linux. The big hint about who's to blame for problems playing any QuickTime movie encoded with the Sorenson codec is hidden somewhere in the name of the codec.
Copying a copyrighted work without the owner's permission is copyright infringement.
Hey look, it's another inconsiderate little shithead.
"Browse at +3", my arse. The fact that you think that's a solution at all shows how fucking stupid you are.
And the thief robbing a bank means the police can investigate an exciting crime instead of writing traffic tickets, makes for interesting news in the local newspapers, invigorates the local economy, and inspires improvements to security all around. In fact, the thief should be congratulated rather than arrested and sentenced!
This philosophy might work in science-fiction books but your name isn't the Stainless Steel Rat.