Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI

Gnome Canvas improves graphics. 74

Posted by CmdrTaco from the stuff-to-poke-on dept.
doobman wrote in to tell us that GNOME has a nice little update online about the new canvas stuff which features (among other things) built in anti aliasing. Yum.
This discussion has been archived. No new comments can be posted.

Gnome Canvas improves graphics. More

Gnome Canvas improves graphics.

Comments Filter:
  • Is there anything about X that makes it inherently heavyweight that wouldn't hurt to throw overboard?
  • apparently not.. :(
  • Posted by kwc1:


    Tigert...

    I use that FVWM2 setup all the time, and I like some of the other incarnations I see in your screenshots. Any chance you could occasionally put more tarballs of your FVWM2 setup on your site?

    TIA!
  • Posted by Federico Mena-Quintero:

    The original Gnome canvas was a port of the Tk canvas, with some extensions (hierarchical groups of items and integration with the Gtk+ object system). The Tk canvas is in turn based on Joel Bartlett's implementation of structured graphics for Scheme.

    Raph then took his insanely great libart functionality and implemented it into the Gnome canvas, giving it antialiasing, alpha-compositing and affine transformation capabilities.
  • Posted by Wolfgang Amadeus Mozart: Music For Your Eyes!:

    I agree it does, but is there a Metal theme available for Enlightenment ? (i know there is one in Icewm that looks really spiffy) metal gtk theme + window manager metal theme = awesome
  • Wel lthats not possible. Unless you rewrite a portion of X, you are stuck with 1 bit clipmasks, and 1 bit font glyphs.

    Youy may get antialiased fonts in your gtk / gnome apps soon, but it won't be via X!
  • I really like the WM setup those screenshots there have. Anyone know what WM it is/where one can pick up the config files?
  • Kick ass, thanks. I compile my own fvwm2 anyhow. :>
  • Like, dude, chill out. We've talked to the
    XF86 folks, and we know that TT is on the way
    in the much-anticipated 4.0 release. However,
    GNOME is supposed to work on all unices, not
    just Linux, and that means working on X servers
    other than XF86. That, not NIH, is why the
    canvas rocks as much as it does.

    Something else that people have failed to mention
    is that the canvas is flicker-free, something
    rarely found in its competitors in the X world.
  • "is hoped to be submitted to the X Consortium for
    inclusion as a standard extension."

    I can't find mention of this anywhere on the
    XF86 web page. Can you point me to the
    announcement/plan document?

  • Canvas (Score:1)

    by raph ( 3148 )
    Absolutely. The Gnome canvas started out in life as a pretty straightforward adaptation of the Tk Canvas. I'm not sure exactly where it showed up first, but it wasn't invented by Borland either :)

    What's cool about this one is its really smooth integration into the Gtk+ object model, and the antialiased rendering back-end.

  • We're looking into that. Of course, this work will be useful even on non-Xfree systems. It can also do alpha-compositing of text and graphics together, which Xfree probably can't do.
  • This is work in progress - the antialiased text integration has not been done yet, even though I do have code for smooth antialiased text rendering from type1 outlines. See this screenshot [levien.com] for a "technology demo."
  • It actually looks pretty decent at 256 colors. We use a 6x6x6 color cube. There are some dithering patterns, but these are pretty much unavoidable.
  • It is also being targeted as a standard X extension.

    The X Typographical Extension returns from the grave?

    I have the impression that there are other complaints about X's font/text handling, such as no support for kerning, and the inability for programs to get enough information about fonts to do printing (or even on-screen formatting?) the way they'd like (I have the impression that's at least one reason why WordPerfect for Linux has its own fonts). Is this extension intended to do more than just allow an X server to draw anti-aliased text?

  • GNOME doesn't need X, and should not make extensive use of X features in a non-portable way. GTK+ runs on Windows now, and should run on things like GGI, SVGAlib, or Berlin.


    Am I the only person who thinks X should die and be replaced with a lightweight window system?


    Bruce

  • GNOME doesn't need X, and should not make extensive use of X features in a non-portable way. GTK+ runs on Windows now, and should run on things like GGI, SVGAlib, or Berlin.


    Am I the only person who thinks X should die and be replaced with a lightweight window system?


    Bruce

  • It seems like the GNOME canvas gives us a lot of features that the advanced free software toolkit Fresco has had all along. (Shameless plug: I compared many Linux GUI toolkits including Fresco and Gtk in my article in the May 1998 issue of Linux Journal. Written almost a year ago, it is still mostly not obsolete, although I didn't have as much experience with Gtk as I do now.)

    Still, shouldn't the Gtk API be modified to put this at the heart of the system, rather than as a parallel add-on? It seems kludgy to have two parallel widget APIs, one for "classic" Gtk widgets and one for "Canvas Item" widgets. Also, quick question: does this this canvas allow for huge scrollable areas with a transparent API? The current Gtk ViewPort widget is incredibly lame with its limitation of 32K x 32K.

    I'm not complaining though. I'm really glad to see a popular widget set (Gtk) get some nice features of a well-designed (but unfortunately didn't catch on) widget set like Fresco. I decided in July, out of all the choices of widget toolkits for Linux, to use Gtk-- for my current project at work. My reasoning was that even though the API was in some ways inferior to, say Fresco or Java's JFC, the incredible momentum behind it would make up for that because so many people are working on the same base. Gtk is also free software, a big advantage over Java and (at the time at least) Qt. Reading about this cool canvas stuff makes me more sure of my decision.

    Michael Babcock
    michael@kanji.com
  • > Canvas items are not Gtk+ widgets. Widgets are derived from GtkWidget, and canvas items are derived from GnomeCanvasItem -- these two have nothing in common except for the base GtkObject.

    Right. This was exactly my point. You've now got two parallel hierachies of widgetry rather than a simple unified functionality common to all widgets. So I have to create and maintain two versions of all my widgets?

    Regarding the layout, does it support a huge widget inside the scrollable area, or merely many 32k x 32k sized widgets spread out over a huge area? A decent viewport, in my opinion, should allow the widget writer to completely forget about the scrollbars and simply have a huge canvas to deal with. Unfortunely the current Gtk design does not allow this because Gdk is not object-oriented. You are passed a rectangle to your draw function which merely has the X level coordinates as 16-bit ints, and you draw using the gdk_* X wrapper functions. You should instead be passed a Graphics object that you draw with. A scrollable viewport would pass you a Graphics-derived object that translates (or even rotates and scales) your coords.

    In summary, it should be possible to write, for example, a text area widget without thought of scrollbars and have it pop in a viewport widget to get scrollbars transparently, with no limitation on the size of the text area. Note that this does _not_ mean you give up the ability to specify proper line and page increments based on the contents of your text area (or whatever widget). See Java Swing's Viewport for an example of this.

    I guess we should be discussing this on the mailing lists.
  • >Am I the only person who thinks X should die and be replaced with a lightweight window system?

    No, but you and the others that think so are wrong.

    Berlin is an interesting experiment in archictecture, but most of their perceived shortcomings of X aren't. Most of them are merely shortcomings with the current XFree86 implementation version 3.2.
  • GtkGLArea is definitely the way to go. There is also a Gtk-- (C++) wrapper for it that I mantain, but I have been too busy with the rapidly pace of gtk-- to keep it up. Gtkglarea can do both rendering in a window and a pixmap. Any GL command seems to work well. (I even got the chose a line working properly.)

    --Karl

  • Am I the only one whose feet hurt after looking at that twisted GNOME logo? I mean, damn, I feel sore thinking about the sorts of orthopedics that poor gnome has to go through. :)

    The reason my head hurts is from slamming my head on the table from their statement regarding image quality: "Please note that the GIF compression may have added artifacts to the images." Sure, if there were more than 256 colors, this may have been the case, but if that was a concern, they could have used a less-colorful titlebar and window decorations, and even as they are they don't look like they'd need 64 colors, much less 256 (though that overly-colorful bitmap in the corner could be a problem). If they didn't want artifacts, they could have just used a somewhat less-colorful test image. Remember, folks, GIF is *non-lossy*. It uses a similar compression scheme to .z, .gz and .zip, and you don't see executables degrading in quality when they're compressed, right?

    Heh, this reminds me of some luser on IRC a few years ago, who was insisting that .zip was a lossy compression scheme. His reasoning was this: "When I install Doom, the graphics are just fine. But then when I zip it then unzip it and get up close to someone, the graphics are all chunky!" I had to explain to him how data is data, .zip doesn't know what's image and what's executable, etc.etc., and if .zip were lossy, then doom wouldn't even *run* much less display lossy graphics quality.

    Anyway. If any image format will cause lossiness, .png will! It's a fractal compression sceheme, IIRC, right?

    That said, the new antialiasing features look very, very nice, althouhg that seems that it'd be at the loss of network-transparency. Although most Linux users these days run their X, clients on the same machine as the server, many still use X terminals in a computer lab in a distributed environment. I hope that there'll be a configuration option to turn anti-aliasing off so that we can keep server-side rendering and reduce the bandwidth overhead (not to mention that server-side is much faster and much less resource-intensive if you have an accelerated graphics card, like almost everyone does now). Anti-aliasing is the sort of thing which should go into the server, not the client, for the most part.
    ---
  • Now, what I'd *really* like to see is an X server based on AA. Wouldn't it be cool to have network-transparent fullscreen ASCII graphics for everything? ASCII-art Netscape!

    Actually, if there's an SVGAlib-based X server, then I guess one could just use the aalib wrapper. Then we could even get X under aalib under graphical X... that'd rock. :)
    ---
  • For the actual rendering, yes, it's easier (though not strictly necessary - as was pointed out, a 666 colorcube works fine, though I prefer 884 aka 332 (bits) since you can optimize it a little better for speed and it gives you more colors - technicolor be damned :) but I was referring to the actual conversion to a .gif. After everything's rendered, it easily takes less than 256 colors. As such, there'd be no artifacts due to GIF compression.
    ---
  • Chalk it up to my never having seen any actual document about PNG. I always thought that was Iterated Systems' partitioned-IFS format, but I guess that doesn't make sense, since Michael Barnsley (mathematical genius that he is) is a cunt when it comes to open standards, and so then there'd be no reason for all these freespeech software products to use it.

    (At the risk of sounding like the "GNUlix" AC troll, IMO it'd be a good idea to use freespeech and freebeer as short for their Richard Stallman-inspired phrases. Makes things easier, but then confuses other issues. English sucks.)

    So PNG is basically an actually-successful format which was inspired by the same circumstances behind POT (basically a 16-bit GIF, which was part of Fractint - which incidentally, Michael Barnsley had a lot to do with as well IIRC).

    Speaking of which, whatever happened to Fractint? It's one of the earliest commonly-used open source programs around for the PC (it's been around since what, '87? or earlier?) and certainly the first both usable by "normal" people (EMACS is great, but give that to a Notepad graduate...) and incredibly powerful for people who knew what they were doing... but development seemed to stagnate after v19.2 or so. Was there ever a decent platform-independent port? xfractint blows, as did winfrac (didn't help that winfrac was based on v12, which horribly sucked)... In the meantime, there's no decent (AFAIK) pluggable mathematical exploration systems around which let you explore basically anything, particularly fractals, and do it very quickly. I mean, okay, XaoS is good for that, but it's mostly artistic, and it's not exactly the most modular/flexible program around...
    ---

  • POT was created for continuous potential fractals. It's really just a 8bit GIF with two images placed side by side, one for the high bits, one for the low, giving you 16bits. Try opening one in a standard paint program, and you'll see what I'm talking about.

    Funny, I never tried that. I always figured it'd just not work. Though the end effect is still that it's a 16bit GIF, more or less. Neat how they made it backwards-compatible like that, though.

    I have xfractint here, and I don't see Barnsley's name appear in the credits.

    Funny, I coulda sworn it did, as did a lot of other big fractal mathemeticians. Perhaps I'm just remembering a different fractal guy, or maybe even just a credit to him for an algorithm or citation. Again, it was IIRC; I haven't used fractint for years.

    Not much. Its currently at v19.6 or thereabouts, and still pretty much just for DOS. The licence isn't very liberal, and the code very platform specific (for performance reasons), so if you wanted to make a decent X Windows fractal program, you'd be better off starting from scratch.

    Hm, I suppose, but I'm not really that dedicated to fractals anymore. :) Guess I could do it nice and C++-ish, and actually use the FPU now that FPUs are worth using. What I really liked about Fractint was the built-in language parser for quick prototyping, though, and I don't have much desire to write one of my own. :) Perhaps making a truly-pluggable architecture would work... just use good ol' gcc as the compiler and just dynamically load the new fractal type as a shared library.


    ---
  • As long as it still has networked display, I'm all in favor of an X replacement. However, I don't know that GGI, SVGAlib, or Berlin have networked displays, and my daily job would be much more difficult without it.
  • So, let me get something straight, this canvas thing is what's telling the X server how to spit pixels out to the screen, and this new version supports on the fly anti-aliasing and alpha channel compositing? Neat. So that means that the mouse cursor will be antialiased and icons will be anti-aliased and the edges can be feathered and cool stuff like that?
  • I don't think anyone claims that we've invented this.

    It's just good that we now have these things available in the free software community.

    We're quickly picking up technology that only the commercial world has had for a while.
  • ..does this seem to be a fair 80% of the way towards a full fledged CorelDraw competitor? (suggested cool name: "gala" for "gnome artistic layout application" :-)
  • Can it antialias the edges of "floating" icons such as used by gmc ??
  • Berlin is lightweight on the network because it has a single shared abstract widget set, and hence need only say to the server end "put a button here" instead of all the code to draw it.
  • It would be fairly trivial to port GDK to Berlin (it does allow X-alike client-drawn widgets) but the apps would stick out like a sore thumb in the otherwise homogenous and well-behaved desktop.
  • If you haven't noticed yet Microsoft would claim they created alot of things (including DOS). Generally if they refer to something extremely impressive or negative then its probably FUD (fear, uncertainty, and doubt)

    doobman

  • Yeah, where the hell does Microsoft get off stealing Apple's 20-year-old sub-pixel font rendering techniques?

    http://www.grc.com/cleartype.htm [grc.com]

  • The GNOME canvas is an extensible display system which allows users to create new items (the items
    you see on the screenshots are the ones provided by the stock gnome libraries).

    New display items are easy to write. For example, the gnumeric spreadsheet is made up of 4 custom canvas items (one of them the grid/cell display). The GXSNMP program also uses it as its main window display code.

    The Gnome icon list (also part of the gnome libraries) is also implemented as a Canvas with various custom items.

    This is a powerful engine that will allow developers to concentrate more on their code, rather than concentrate on handling little GUI details
  • If I'm not mistaken, PNG is not lossy. PNG is largely GIF's cousin in that it's based on LZ77 where GIF is based on LZW. This is not unlike te differences between compress (.Z)/zip(.zip) and gzip(.gz). If I remember my File Structructes class correctly, LZ77 is completely public domain and then Welsch(sp) came along, made some modifications that improve the performance(arguably worsened file size) and patented it. Hence LZW.

    For real info goto:

    http://www.cdrom.com/pub/png/ [cdrom.com]

    -Alan

  • Take a look at this screenshot [gimp.org] to see some rotating of the canvas.

    And keep in mind this is work in progress.

    tigert

  • Delphi is good. I'm the lead programmer at Gleim Publications, Inc. (www.gleim.com), and we've been using Delphi (1, 3, and I've been playing around with 4) for our Windows software. It's a great tool for Windows programming, because it takes so much of the overhead out of the picture, while still allowing you to directly access the API when you need. And damn, does it ever compile quickly.

    BUT, Object Pascal isn't that great of a language. I have run into the languages limits, but I've been able to work around them. However, there are better lanuages, mainly Java and C. C++ is nice, but it appeals mainly to the esoteric nature of hackers. As a language, it's got some problems. So, I'm happy working as a Delphi programmer.
    Now, if only there was a Linux/X11 version, I'd be in heaven.
  • oh yeah, its illegal...no one else uses anti-aliasing. when your playing quake, thats not anti-aliasing and mip-mapping thats making those smooth polygons...
  • Berlin isn't likely to be lightweight since they have included a widget system in the display server.

    Maybe Chris Toshok's Y Window System [hungry.com] will happen, but X compatibility (via a libX11 proxy lib or proxy X server) will be required forever.
  • How well do canvas-based apps perform when displayed over a network? If the answer is as bad as I imagine, what are the chances of someday seeing a libart extension for X?

    Thanks Raph for pushing Linux graphics a giant step forward!
  • Yes indeed, Jeffrey, I know what you mean you say that. Having enjoyed beautifully AA'd sub-pixel accurate font rendering since 1989 on my aged out of date Acorn Risc PC, I'm really missing the beauty of a thorough integrated and flexible AA font system. I guess one of the nice things about the Acorn AA font system was that it was universality enforced on the entire GUI and all apps. Apps did not have to be told to AA the fonts. However, if you didn't like the AA'ing in your app, you had to option of turning it off selectively for each app. A nice approach, and did wonders to readability of text it small text sizes. Greeking was never a necessity on Risc OS since 6pt text was perfectly readable! Although I'm thankful I've left the aged Risc OS/Acorn platform, I do admit it had some nice bits which would be tremendous to see in Linux WM near us :-) I'll be keeping a close eye on such developments over the months as I slowly get into my brand new Linux set up which I'm enjoying very much, I must say....
  • I'm not sure WHO invented text AA but back in 1987, Acorn Computers Ltd created a system wide, GUI integrated AA outline font system which to this day stands its own ground. It's a pitty, RISC OS fell behind and Acorn's marketting 'Arm' never existed. Without getting into Acorn preaching (I used to rave about them back when they were genuinly ahead of the game, but sadly they're not anymore, for a long long long time), I had the luxury of a highly sophisticated AA font system for a long long time, and I'm really looking forward to seeing something similar for Linux.

Slashdot Top Deals

"Time is money and money can't buy you love and I love your outfit" - T.H.U.N.D.E.R. #1

Close