From kde-core-devel Sun Nov 10 20:12:21 2002 From: Carl Worth Date: Sun, 10 Nov 2002 20:12:21 +0000 To: kde-core-devel Subject: Re: Fwd: Announcing XSVG mailing list (keywords: Xr, Xc, Postscript-like API for drawing in X) X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103700064919717 On Nov 10, Vadim Plessky wrote: > On Sunday 10 November 2002 7:51 pm, Hetz Ben Hamo wrote: > | > | 2. The Xr author mentioned that he hacked glib, gdk, pango, etc - but not > | QT which is being used a lot on KDE, so are there any QT hacks? I'm the Xr author. I don't know what statement is being referred to above, but I haven't hacked glib, gdk, pango, etc. to use Xr, (although I did make libsvg by hacking librsvg to *remove* these dependencies). I would like to see both Gnome and KDE environments take advantage of Xr, (and therefore RENDER). From what I've seen, it should actually be quite simple to get QT ported to use Xr. On the other hand, moving from libart to Xr might be a little trickier. It might make sense for someone to make a compatibility library to ease this task. > | 3. I was wondering about speed of graphics card which supports the Xr/Xc > | comapred to older cards which won't have this feature in their driver - > | any numbers? Xr/Xc are client-side libraries, (not extensions), and therefore do not need any driver support. Xc will use the RENDER extension if available, so RENDER is the only piece that needs driver support for good hardware acceleration for everything. All Xr/Xc rendering eventually decomposes into rasterizing trapezoids or compositing translucent images within RENDER. I would think it should be quite feasible to accelerate both of these operations on modern graphics hardware. -Carl -- Carl Worth USC Information Sciences Institute cworth@east.isi.edu 3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725