[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fwd: Announcing XSVG mailing list (keywords: Xr, Xc, Postscript-like API for drawing in X)
From:       Carl Worth <cworth () east ! isi ! edu>
Date:       2002-11-10 20:12:21
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]