Slashdot Mirror
Xgl Developer Calls it Quits
nosoupforyou writes "Jon Smirl, one of two main developers for Xgl and Xegl (a version of X layered on top of OpenGL and rendering directly to the linux framebuffer, similar to Apple's Quartz Extreme) is calling it quits. Citing two years of effort without pay, a shortage of interest from developers, and no hope of release for more than a year, Jon is moving on."
Xgl has been heavily backed by Novell/RedHat and the gnome fanboys (well, by 'backed' I mean hyped as if this was going to save gnome's arse), but the real work in X is being payed for by that favorite FOSS company that gives so much, but everyone loves to hate: Trolltech.
Here you have it folks. It is now time for the gnome fanboys to jump off of the Xgl bandwagon. And thank Trolltech for coming up with exa that will allow composite to work with todays existing stuff. Of course, with Trolltech employing the developers you can guess which desktop is going to have the advantage of bringing all the new eye candy to market...
considering the dearth of posts on slashdot i'd say no one cares that he quit.
I was really looking forward to the completion of this project. This is what we all need to accomplish the goal of bringing Linux to the desktop. We need to be able to make a, what we're calling at Plasma, a "designer desktop" that everyone will love and enjoy.
:-p
I'm surprised that Trolltech hasn't looked into and started contributing to this. They recently hired someone specifically to work on the enhancement of X and bringing its eye-candy and performance capabilities up to the point where it can compete with things like MacOS X without slowing down horrible.
Trolltech, save us!
If you like what I've said here, and want to read more, go to http://www.krillrblog.com
Hopefully now more effort will be made towards core functionality and better drivers rather than wasting time on annoying eye candy CPU drain. Mod me troll if you will, but I for one would rather have time devoted to proper usable drivers for modern graphics cards than some silly extras that eat all my CPU and RAM but contribute nothing towards functionality or productivity.
Forgive my appeal to authority but,
Nat Friedman: "Xgl opens up a whole world of hardware acceleration, fancy animations, separating hardware resolution from software resolution, and more"
To those moaning about the lack of better video drivers, From wikipedia: "Structuring all rendering on top of Opengl should simplify modern video driver development and not have the separation of 2D and 3D acceleration." That means vendors would have an easier time giving you your "better drivers".
And of course OS X and Longhorn have already gone this route, placing FOSS behind the times.
And finally, you can have both improved current X and Xegl. Witness the recent Exa buzz (replacement X acceleration architecture); current X is getting a boost already, Xegl doesn't slow this in any way, however Exa is slowing Xegl apparently.
i find it a shame that these projects, which seem to be the only things that could save us from x11 (along with its 16-bit code), are going downhill from negligence.
its all complicated code that's hard to contribute too, mixed with slow progress that will lose fans. ive been looking at y-windows ever since it appeared on slashdot a couple years ago, but its seemed to have died down almost to the point of giving up.
it'd be nice if groups like Trolltech or Red-hat could fund these groups, to help one of the more important aspects of the open source desktop that is sublimely promised within the next decade.
You don't know anything do you?
1) Modern video cards are 3d accelerated
2) 3d is a generic superset of 2d
3) GPUs are nearly more powerful (if not clearly) than CPUs
4) More graphics == more information
5) More information == more productivity
Assertion: 3d accelerated UIs reduce CPU usage (because more/all user feedback is handled by the GPU instead of the CPU, point 1, 2, 3, and 4), and provide improved usability (points 4 and 5).
The loss of this effort also has negative consequences: Driver development is stalled between 2d and 3d (points 1 and 2), rather than just developing one set of drivers, and UI improvements are stalled (because loss of point 3 limits, to the CPU, improvements in points 4 and 5).
Here are examples of how 3d acceleration can be used to "increase" productivity:
Using 3d hardware to render fonts at high resolution and fidelity to the screen. Improved rendering reduces eyestrain by increasing readability. If it is easier to distinguish between an 'l', 'i', '1', and '|', that's an easier time during coding. The same for 'O' and '0', and 'g', '9', and other similar characters. Higher resolutions require more rendering horsepower, and assigning it to the GPU means less drain on the CPU.
Higher resolution displays will in general have more information; more information translates to higher graphical load, such as number of windows, number of characters, number of graphic elements, and the numerous interactions between all of them. If you can use z buffers and stencil buffers to manage all of these elements, that removes the load on the CPU to manage window, character, and graphic redraw. If you use shaders and vertex transforms to handle font rendering and drawing, you get improved fonts and displays without eating up CPU time. If you use blending modes and texturing hardware to handle window drawing, that's less CPU drain when determining what gets updated, how it gets updated, and when it gets updated.
Then there are the SFX that can only be done with GPUs (rather than wasting CPU power). Window scaling and window transformation, rather than relying on the CPU to handle window resizing, zooming and minimizing, and window movement.
Instead, you'd rather waste CPU cycles on all of those effects!
GPL Deconstructed
I know how it feels to have people neglect your work... But it's a pity that he's throwing in the towel at this point.
Cairo, the main consumer of Xgl/Xegl, is just nearing version 1.0, and will be used by the new releases of Gtk/Gnome. Also, once Gecko 1.8 is out the door the plan is to move the entire Gecko GFX architecture to Cairo. It already uses it for SVG rendering. So some of the big boys are coming to the party!
Hopefully things will pick up and he'll return to it soon...
Regards,
-Jeremy
Part of the problem is resources. There just isn't enough being spent by graphics folks on, well, graphics. SGI had some amazing graphics. Once. OpenGL was revolutionary. Once. Then they kinda lost their way and are now on the verge of extinction - ironically, just as they're beginning to revolutionize supercomputer Linux with their Altix cluster.
Of course, it doesn't help that many brand-name graphics chip designers have Top Secret APIs for their products. Yeesh! From theater to Ford Motor Cars, plenty have realized that what matters is bums on seats. If you have the numbers, you'll win. IBM nearly killed itself trying to prove otherwise, as did Transmeta. Bought an ICL computer lately?
As far as GUI interfaces goes, the same logic applies. What matters is the number of users. From that perspective, it would seem logical for chip manufacturers to build the whole of the client-side of the GUI into the chips. Whoever gets there first will rule the GUI market for some considerable time and competitor hardware GUIs will have a harder time of it.
Won't happen, for the same reason Winmodems became popular. It's cheaper to let Microsoft define the standards and build around what Microsoft won't provide. At which point, writing competing GUIs is pointless, as the only efficient GUI will be one that is identical to Microsoft's.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I have to wonder if you've ever done any OpenGL programming. OpenGL has sub-pixel rendering, its pixel-alignment algorithms are documented, and it has support for whatever natural units you like. (In my most recent screensaver, I set it up to work in cm.) It doesn't have color matching, but then again neither does X.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
For me, and lots of other people and companies, every year is a new year of GNU/Linux. It's already there, and has been there for a while. :)
Here it is presented a way to not just only GPU accelerate the rasterisation but also the tessalation of the vector primitives.
t m.pdf
link:
www.loria.fr/~levy/publications/papers/2005/VTM/v
abstract:
"This paper presents VTMs (Vector Texture Maps), a novel representation of vector images that can be used as a texture by the GPU for real-time rendering. A VTM decomposes texture space into different regions, represented in an analytic way, by a set of implicit degree 3 polynomials. Each region can be rendered by a different fragment shading function. Accurate anti-aliasing is performed in real-time, based on an estimate of fragment coverage. As a consequence, infinite zooming can be applied without any pixel discretization artifact. Based on a hierarchical data structure, our representation has low memory requirements. Its versatility is demonstrated in various settings, including a font engine completely implemented in the GPU."
No, I think you're still wrong. See, OpenGL doesn't have any kind of scalable font support, subpixel-rendered or not. You draw fonts via OpenGL by rendering the fonts to either a bitmap, or to OpenGL primitives.
OpenGL does have subpixel antialiasing on its primitives. It doesn't do the "cooltype" thing, because the precise details of the pixel coverage algorithm are driver-dependent. However, there's nothing stopping your font renderer from turning your typeface into OpenGL geometry, and having your OpenGL driver render the geometry with cooltype anti-aliasing, so it's not a limitation of OpenGL.
So OpenGL supports subpixel rendering of fonts just fine, via bitmaps or via geometry. It doesn't render your TrueType fonts to a subpixel optimized LCD-ready bitmap, but that's not its job. OpenGL doesn't pretend to be a font renderer or hardware driver.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Well, that would be the "sufficently complex shader program" then. Quite useful looking, if you've got a modern GPU - maybe good way to encode quite complicated surface details without megabytes upon megabytes of bitmapped textures.
But: that paper doesn't actually deal with how to do subpixelling on-GPU with shaders, only antialiasing of the "vector-texture-maps": though in principle, and, hey, as previously stated, subpixelling (i.e. treating ordered red, green and blue subpixels as separate luma pixels for rendering for extra-sharp discontinuities such as the edges of fonts) should be possible with an even more complex shader - antialiasing and subpixeling are related, but one tends to makes fonts blurrier and the other sharper!
P.S. would it have killed you to use the <URL:http://example/com> tag for your link? See the "URLs" example right below the comment box!
Why is everybody bemoaning the demise of Xgl?
The main point, to me, is the reason nobody's interested any more: X11 is getting better and, with recent extensions such as EXA and all that composite stuff, has caught up in terms of eyecandiness. The niche for the project no longer exists as Xorg-X11 proper is starting to fill it. And that's a good thing.
Something to think about.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Sorry, but who the hell cares if subpixel aliasing is exactly the same across different OpenGL drivers or not?
And if there is a really good reason why it needs to be, all you need is for the driver implementors or font rasterizer implementors to agree on what algorithm they're going to use. Again, the fact that OpenGL doesn't demand a specific algorithm doesn't mean that OpenGL doesn't support subpixel antialiasing, which was the original complaint.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
> Sorry, but who the hell cares if subpixel aliasing is exactly the same across different OpenGL drivers or not?
Well, people who wants to make application with readable fonts.
'All you need' in practice, there is no way that all those implementors will agree to a common algorithm unless it is standardised somewhere, and even in this case, there shall some kind of stick&carrot to ensure compliance otherwise they won't bother.
He didn't say OpenGL prevents subpixel rendering, he said 'doesn't support' which is true: OpenGL does nothing to support subpixel rendering, so it doesn't support it.
Right, but OpenGL does nothing to prevent it either. It simply isn't a sensible issue, it's like complaining that sendmail doesn't support file attachments. It's not supposed to, that's a higher-level feature.
And I still don't see that variation in font rendering algorithms is a big deal. Plenty of people make graphic design packages for the Mac, and font rendering there depends on user settings.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
It doesn't have color matching, but then again it should be easy to add if drivers supported the GL_ARB_Imaging extension properly.
As a simple example of scaling r,g,b you can use something like..
float color_croma = { dr,0,0,0,
0,dg,0,0,
0,0,db,0,
0,0,0,1 };
glMatrixMode(GL_COLOR);
glLoadMatrixf(color_croma);
and with a 4^2 matrix it's also easy to adjust things like the hew and saturation and anything else you'd need for colour matching.
Judging by the replies in the actual thread he posted on, and the low number of /. replies...who cares?
Sig & Below
Yuck Fou
OS X, yes. Longhorn? Not --- it's not a shipping product any more than Xgl is, and even the much bemoaned "1 year from release" still puts Xgl at a release around the time of longhorn.
A deep unwavering belief is a sure sign you're missing something...
OpenGL doesn't have any scalable font support because there is no need for it to have any. Scalable fonts are always pre-rendered to bitmaps, and OpenGL (via pixel shaders), does have the capability to composite those bitmaps to the screen in a way that preserves sub-pixel anti-aliasing.
A deep unwavering belief is a sure sign you're missing something...