Slashdot Mirror

This is a big step forward. Something I've waited for a long time. If it is possible to unite all those vector-graphics efforts in cairo more time can be spent on "stuff that matters".

Well, I always hoped X11 would do this step but they seem to enjoy doing politics instead of standards... On the other hand this approach has some unique advantages:

• Platform independence: runs on win32 and linux, awaiting os x...
• Can work without X11...especially interesting in not-so-full-powered-configurations (directly via OpenGL)
• Independent... People at freedesktop seem to do the trick very well (they didn't get between the lines -- yet)

Interesting is, that there are also java-bindings that work together with SWT which is an interesting step (mono is already on board -- see previous comments)

So hopefully the time of ugly graphics in platform-independent OpenSource-Software is finally over... (just watch OpenOffice -- uaaahh)

Well, a last wish: If Qt guys come aboard, this means KDE is in which on the other hand means that gnome and KDE join on the same backend... just dreaming...

Hmm...since Cairo is out and Avalon isn't, the Penguin now has a step up on Redmond in terms of graphics. Granted, Avalon includes some other spiffy 3d eye candy, but this is a first where the Linux GUI beats out the Windows one.

What's your definition of "out"? From the Cairo download page, "Cairo is still under active development. The API is rapidly approaching stability, but is not quite there yet, so there is not yet any official "release" of cairo." So, Cairo is not a 1.0 release, or even a .01 release. Dev snapshots are available, in an unstable form (the API is "approaching" stability). How does this differ from the available technology preview of Avalon (aside from the openness of the source, of course)?

Both are still in pre-release stages. Both are available in a publicly-consumable form even though they've not reached API stability yet. Declaring one or the other the "winner" is still premature.

Oh, yeah, and Avalon will be available on XP and 2k3, not just Longhorn.

Note that the Linux equivalent of Quartz is a rendering subsystem called "Cairo". It's not widely-used yet, mind, but that is likely change quickly in the usual catastrophe-curve adoption pattern typical of the linux community.

Quartz just ain't "light years ahead of everything else".

As Linux doesn't have GDI+ I doubt very much that it will work with Mono.

There is another problem with porting Paint.NET though: Ink, the TabletPC SDK, which is heavily used according to the creators of Paint.NET, is not part of Mono. Not yet at least.

90% of anything the average user does daily is RASTER.

I didn't say otherwise.

Most fonts are vector fonts. Not all, but most. Maybe this will change.

About as likely as reverting to punchcards.

I wouldn't say that X11 dosen't have vector graphics

I didn't write that. I write X11 doesn't have device-independent vector graphics. And it certainly doesn't have anything near the capabilities we're talking about here. What do you think Cairo is all about?

I'm not remotely excited about `true' transparency and drop shadows - features which are no use beyond looking pretty for me. However I can see that in order to get support, which is what an OSS project thrives on, the screenshot-happy users need to be pleased. So in that regard I think such developments are a trade-off.

What significant X developments would impact me? Well, has anyone tried adding a 3rd-party driver to X? I have to download the entire x source (apt-get source xfree86) and stick a diff from aiptektablet into the debian patch directory and build the whole freakin` thing (which, with .o's, clocks in over 300MB) in order to get my graphics tablet to work. Thats an enormous download and compile job when a mere fraction of that code and the result is needed. Streamlining and simplifying this process would allow more people to experiment with x hacks and make our lives easier.

I think hardware support for vector rendering will be a great benefit to how quickly window-manager and toolkit operations are performed - anyone profiled a GTK2 app recently, and seen the slice pango takes up?

Finally there is a lot of innovation going on outside of the x.org project which I think is equally as important as the framework - examples of next-generation window management such as ion and devil's pie show where I think things are moving for power-users.

There's a lot to be done in the field of API:s.

Basically, I'd like to see a good and definitive API for vector graphics. This is something still very lacking.

Preferably, the API would handle:
* High-quality printing
* Export to PS,SVG,PDF
* Bitmap rendering (for on-screen drawing)
* Support transparency
* Be well integrated with the font API:s.

Basically, a unification of all 2d graphics things into one single device-independent API.

Apple already has something similar to this in Quartz.

Supposedly, Cairo is supposed to do this, but given that there is no real documentation or roadmap for it, it's hard to say how, when or if it will ever get there.

It would be nice to see some of the Linux GUI developers implement a fully vector-based scalable windowing system.

It's sort of happening already.

SVG in GNOME and KDE. That's scalable vector graphics at the application level. Some themes already use SVG for icons and window decorations.

CAIRO offers scalable vector graphics at the X11 level. Nice pics here. Hardware acceleration through Xrender.

Windows are getting alpha channels thanks to XDamage, XFixes and XComposite. Means we'll finally start seeing similar effects to what you get with Aqua on MacOS X.

All the bits are coming together. If you're willing to play at the bleeding edge then you can see some of these effects today.

Cairo

Wish I had a doller everytime some mentions this.

I think Flash is good for devices.

I always thought that it'd be nice to have a PDA based entirely on Flash, where all the apps were Flash-based/-authored, etc.

Since I work for a hardware developer I've thought this quite a few times. Its really too bad there aren't any good embedded-Flash based systems around that can be incorporated into devices ... guess we'll just have to think about using Cairo... when its finished.

I'm not sure what you mean by "XML parsing (last time I checked SVG couldn't do that in its authoring tool)"--what is the SVG authoring tool? Sodipodi or such?

The authoring tool--if that means editor--what I use is a text editor--in jEdit, for example, with the dandy XML plug-ins installed (thank y'all who work on all that), the SVG gets parsed & validated against the DTD, keeps things clean--did you mean something else by "XML parsing"?

Your other two points are clear, & largely accurate.

For video--& if you're using Flash as the comparison, I guess you mean synchronized sound and animation--that isn't really part of the intention of SVG's design. For that, look critically to SMIL.

Browser support on the web--aiiee--you got that right, apart from Amaya. Surprised me, how excited I got when Brendan Eich declared native SVG support a priority. Come on, Cairo, come on, come on.

The two projects you mentioned are actually toys. They are nowhere near the magnitude of what Looking Glass offers, namely an infrastructure for building 3D desktop enviroments. The 3D window manager is not the important parts, it's the actual technology that enables it;

What most folks seem to overlook is that this Looking Glass is actually built on top of Keith Packards Composite and Damage X extensions. Coupled with something like Cairo you actually have a pretty kick-ass infrastructure which is able to compete with the big boys.

-adnans

Case in point: I wanted to compile cairo on my Mandrake 9.1 system. I couldn't until I edited the autoconf file to remove "new commands" and added phony files to make pkgconfig happy. Then it compiled just fine and worked. I tried to compile the demos and was completely frustrated and eventually hand-wrote a trivial makefile and they all compiled just fine and worked (except for the GTK one...). I am now trying to compile the "Glitz" OpenGL backend, and I am running into the same troubles: I can't prove it yet, but I strongly suspect it will compile just fine on my machine, if I can just get around the mysteries and complaints of autoconf/automake/pkgconfig, probably by wasting a great deal of time and divining the basic, and probably simple, Makefile that would compile it.

The incredibly frustrating, and dare I say stupid thing is that the only thing I need to "update" on my machine is the damn autoconf tools! I actually have all the libraries and headers these things need. That is completely backwards! In fact due to autoconf they have pretty much said "this only compiles on the very newest experimental Linux system". Well in that case, you have eliminated the need for "autoconf" and you could send out Makefiles that work only on a new Linux system. That would probably be easier for somebody like me to edit and get working on an older system.

When you do try to fix this, you run into the horrifyingly bad syntax and rules of M4 and GMake. Supposedly this is because they want to be back-compatable and run on older systems. But they lie when they freely add new "autoconf" commands so that the newest version is needed. Why not scrap the whole thing and try a modern syntax?

My proposed solution: make ONE compiled program that does "configure" and "make" and "make depend" (and "install" and "uninstall" and "clean" and "dist" and all the other special-cased targets...). This program can use the existing automake/conf stuff so it can be compiled for multiple platforms. The program then reads one file, in editable text (no XML, and it should be trivial to add/remove a source file by adding/deleting a line). This file should be parsed in a procedural way, with "if" and "for" statements and functions (ie it is perl or something) and the result should be the dependencies tree and it can then run the programs (the result is extremely static and has actual filenames and commands, not templates or "rules"). Make it really easy to add and remove switches to the compiler. Make it save user answers to questions in a file so it can provide those answers again, and make a gui program that provides panels and checkboxes to change those user answers. Make it automatically check for dependencies in any C style source files by looking for "#include" without running the compiler, and save the results in a binary database with date stamps so it can run this instantly as needed. Any package dependenciies should be checked with "if" statements in the file, the program would have enough commands to do typical file system things like look for files or grep a file for something, and it is then trivial to write a file that checks for something in multiple places by using "if-else" statements.

What makes SVG even cooler is that we have the perfect rendering technology for it: Cairo. Cairo renders perfectly stroked and antialiased SVG for a variety of backends including bitmaps, PostScript, and X11.

Hopefully the SVG projects will either adopt the existing Cairo SVG code or use the Cairo rendering code as a backend for their SVG libraries.

I hate X-Windows, crappy widgets and horrible fonts.

Even NeXtstep and OPENSTEP's use of Display Postscript was excellent on low powered Intel based hardware.

At least GTK is planning to switch to it, I guess QT as well.

I'm wondering how long before we see this in XFree86.

It probably won't go into XFree86. The freedesktop.org X server contains a rewritten core and relies on many X extensions that the XFree86 project is really not embracing. Despite the good work the XFree86 team has done over the years, they have a long history of hesitation and, even worse, conflict with those that would take XFree86 in a non-standardised direction.

I applaud the new efforts on freedesktop.org, especially by the evergreen Keith Packard, and this is what we need to see in the FLOSS world.

X11 is one of the few areas where there is no real competition between projects. Linux vs. BSDs (vs. each other) or KDE vs. GNOME. It's healthy; it pushes the projects to higher levels of progress. Once freedesktop.org's X server is ready for mass consumption (hopefully not too long) then this 'lack of competition' changes.

FLOSS will see a whole new world of graphical coolness as Window Managers and Desktop Environments add Compositing Managers to produce awesome effects using freedesktop.org's X server and the group of projects supporting it.

The freedesktop.org X server intermingles with things like Cairo and lots of other exntensions. Conversely, XFree86 seems to fight any hopeful extensions.

What will happen is that in a couple of years, many DEs and WMs will ship with a 'feature X requires freedesktop.org's X server and will not work with XFree86' and XFree86 will lose backing and momentum.

The only downside to freedesktop.org's X server is that it will no longer run well on a 20mhz 486.

Yeah, I don't care either. :)

So far Linux seems to be ahead of them in development, I mean Storage Slicker and then theres xouvert , cairographics and project Y.

Cairo? ;-)

http://gtk-themes.cairographics.org/

Screenshots here, here and here.

If we can all see this why cant they? I dont know what their goal is with SVG, but do I really care if SVG is a Kpart if its not truely a part of KDE or X? Everyone here please check out http://cairographics.org/ CairoGraphics is a project working on making the entire interface SVG, and allowing my state of the art graphics card to render that interface, this means speed. I don't want a cheap software rendered SVG hack which wastes CPU resources, I want it to be done right, why do we have all these SVG projects when they could just merge into one project?

Wheee, I thought Fresco (fka Berlin) had had trouble. ;)

While this may be good news for Cairo) and Fresco, in giving them more time, it may also indicate something else, that Microsoft found out that the hardware is not and will not be good enough (even if I doubt that idea).