Slashdot Mirror
Gnome Canvas improves graphics.
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.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Yum indeed.
Too bad the text rendered on the new canvas looks like ass. And text clipping appears to have broken.
Otherwise a huge leap for the canvas! The line art and alpha-composited polygons look stupendous.
I lust for an anti-aliased TT font server for X.
Jeffrey
hasn't been 20 minutes and she's been /.'ed to death!
Just for reference. The canvas has been around for a while in Borland delphi. It is a property of most of the graphical components. Not that winblows or programming for it are important to /. I just want to let you know this idea isn't original.
Something like this would help in writing a cad
program (like Autocad) clone since it accepts
coordinates in floating point, does scaling,
clipping, etc. which is very important is cad
programs.
Hey, isn't anti-aliasing a Microsoft technology? I saw a press release not long ago saying they invented it...
It's pretty easy to get an Xwindow pointer from a GDK window, so you can just set up an OpenGL context like you would if you weren't using a widget set. It's not too difficult; I've combined GTK+ and Mesa a couple of times.
Please get this code in. Also include freetype support.. PLEASE?!?!
Isn't it possible to request the character multiple times from the xserver at slightly differnt sizes? Isn't this how the gimp does AA text? If so then you wouldn't need explicite freetype support.
Antialias text/TT is being integrated into the X server for XFree86 4.0. These guys should of talked to the XFree guys. Of course, NIH probably took over...
Well, Type 1 fonts are so poorly hinted that it almost isn't worth the effort to write an anti-aliasing renderer for them. I use all TT fonts in my current X setup, not anti-aliased, of course.
BeOS R4 includes support for Type 1 fonts, and it is really amazing how much better the TT fonts look when you see them side-by-side on a system where everything is subpixel-accurate and anti-aliased.
Jeffrey
Yeah, where the hell does gnulix get off stealing Microsoft's Crytal text technology?
Umm, doesn't LIBGGI2D already do this? With [in theory] acceleration? Aarrgh, I wish more people would learn about GGI and stop having to reinvent the wheel....
I can't WAIT until GGI supports GTK or whatever, or has some sort of X wrapper... I don't really like windowing systems/mice, I'd much rather have an application running fullscreen and use the keyboard to interface with it. Remember, mice are evil because they want you to use them so you don't learn how to use the keyboard so they can get rid of keyboards so they can get rid of written language so you are easier to control.
GGI has a network display target.
Of course it's legal. Anti-aliasing refers to everyday signal processing, not just font rendering!
You antialias a signal by low-pass filtering it prior to sampling it in order to limit its frequency content (bandwidth) to less than 1/2 the sampling frequency. (When talking about fonts, or other images for that matter, the units of frequency are 1/unit length, known as spatial frequency). After anti-aliasing, a signal can be reconstructed with minimal aliasing (distortion at the signal's higher frequencies, which causes fonts to look "shitty" as someone else's comment said).
Refer to a Signals & Systems text or a Digital Signal Processing text for more in-depth theory...
I go to this webpage and Netscape says: Downloading 1% of 1768K complete.
What the fucking shit hell is wrong with those people.
I tried Fresco (just before the current release) last October. There's still a few people working on it and an low-activity mailing list. It's a good thing, but there's not much support or documentation other than a fine Tutorial and a big Reference manual.
I created a page with quite alot of stuff about it, including some hints on getting started.
Fresco page of Gary's Encyclopedia
The picture was reduced in size so, I guess that
could distort the picture.
Watch out on comparing those monitor resolutions.
Those monitors have the bandwidth to do that kind of resolution, but they don't have anywhere near the dot pitch to actually resolve each of those pixels discreetly.
Also, I'd like to suggest that if Gnome does start supporting AA of fonts, you guys do it in such a way that when the X protocol is ever revamped/replaced to support AA from the X server, it is a completely transparent change to the average gnome programmer.
Danka
Just AA font is not enough for drawing program such as Corol Draw or Illustrator. Getting vector font data through X server or font server is also need.
IMHO, I hope AA feature is implemeneted by adding a hint of antialiasing to extented GC.
hey, idiot, of _course_ all the antialiasing is done at the server.
this canvas is merely a library to permit drawing basic shit in a gnome window. it operates similarly to the library that allows menu bars, clicky-buttons, scrollbars, etc.: it simply does the calculations and throws the results at the x server to display. it will take up no more bandwidth than any other x window with lots of graphics stuff in it.
i wouldn't even know how to go about implementing this stupid client-side add-on x library you wrongly imagine the gnome canvas to be. it would take some serious changes to the x server, wouldn't it?
It also sounds like it has some of the same features as the cool new Graphics2D context in JFC.
:)
Maybe it would make a GTK version of my Java library easier if I ever decided to do it.
Snoop Baron
to lazy to login
gfonted looks like it rules...!
If what you say is true, IBM should take legal action against Microsoft, since anti-aliasing was AFAIK invented at IBM (please correct me if I'm wrong)
Please show me how to save a 24-bit-depth image with *no loss of quality* in GIF format. (HINT: GIF is an 8-bit format. It's un-FUCKING-possible!)
Next time you quote, don't change the fucking wording. "GIF compression" doesn't equal "GIF dithering/quantization." Granted, this isn't generally left to some GIF plugin or library; but still, the person who wrote the text was being terse. At least they didn't misquote to make a fucking point.
Asshole.
Its been around a while in a few other languages as well. I don't know where you got the idea that anyone thought the canvas was original? Did you know other programming tools used the pascal language before delphi? Wow huh?
"in theory" being the relevant phrase here.
In any case, X is currently the standard, so
even if you used GGI with all its fabulous
features as a backend for X, you'd still have
to extend X to make use of all those features,
and provide them to the client.
Most people don't want to write fun desktop
apps that have to run full screen.
When GGI is ready, I'm sure someone will make
the canvas work with it to provide accel'd
AA and other bells and whistles, if such a
thing could be possible.
- is the entire rendered image cached on
:)
the client side? Or are the objects rendered
as needed to buffers as large as the expose
regions? I'm just curious about mem requirements
for eg. a full screen canvas widget.
You could get superfast expose update by
cacheing the entire thing in a pixmap, and
setting this to the window background...
- how do embedded widgets handle transformations?
I guess I should just read the docs. Great
work though. Especially GdkRGB. Makes raster
graphics under X easy. Thanks!
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?
What's cool about this one is its really smooth integration into the Gtk+ object model, and the antialiased rendering back-end.
LILO boot: linux init=/usr/bin/emacs
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.
LILO boot: linux init=/usr/bin/emacs
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 for a "technology demo."
LILO boot: linux init=/usr/bin/emacs
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.
LILO boot: linux init=/usr/bin/emacs
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?
Am I the only person who thinks X should die and be replaced with a lightweight window system?
Bruce
Bruce Perens.
Am I the only person who thinks X should die and be replaced with a lightweight window system?
Bruce
Bruce Perens.
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.
--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. :)
.z, .gz and .zip, and you don't see executables degrading in quality when they're compressed, right?
.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.
.png will! It's a fractal compression sceheme, IIRC, right?
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
Heh, this reminds me of some luser on IRC a few years ago, who was insisting that
Anyway. If any image format will cause lossiness,
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.
---
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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.
---
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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.
---
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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...
---
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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.
---
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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?
-Ben
bensmith@biz1.net
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
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
For real info goto:
http://www.cdrom.com/pub/png/
-Alan
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 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.