Fwd: Announcing XSVG mailing list (keywords: Xr, Xc, Postscript-like API for drawing in X)

[Vadim Plessky]

On Sunday 10 November 2002 7:51 pm, Hetz Ben Hamo wrote:
|  > There are high chances that this library will find its way into XFree86
|  > core distribution, and become present on *any* Linux Desktop. Or just
|  > becomes low-level library installed on pair with libpng, etc.
|  > Therefor, SVG can become very common and widely used.
|  > Xr and Xc are new XFree86 extensions, Carl Worth is working on those
|  > extensions together with Keith Packard (the man behind RENDER
|  > extension). Those extensions would be part of upcoming XFree86 4.3.0
|
|  Hmm, few questions if you don't mind:
|
|  1. Isn't it what Mac OS X does? (I think it's called "quartz" - not sure
| about the term)

AFAIK MacOS X's Quartz API is rendering API based on PDF.
I don't know whether Quartz has some support for SVG.
And, most likely, Quartz is implemented at software-level (no hardware 
acceleration). But I can be wrong here.

|
|  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? or this
| extension is going to be using the QT's OpenGL extension? (remember, next
| QT major version will only be available in around 9-12 months time). This
| point is not explained well, I'm affraid..

See [1] below

|
|  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?

I think Carl can provide some details on it.
Intention is to make things faster, idea behind Xr is hardware acceleration 
(when possible) and fallback on software rasterization when hardware 
acceleration is not possible.
Current/existing implementations of AA renderer (libart, ImageMagick, FreeType 
AA gray renderer) are software-only. But performance is still ok (and even 
*very good*, like in case of FreeType).  
With hardware acceleration in place, things can be even better! :-)

|
|  Thanks,
|  Hetz

[1]  Quoting Rob Buis and Carl Worth:
---------------------------------------------------------------------------------
> Xr provides an API that is very much like the Postscript drawing API,
> (also much like the SVG graphics operations). Typical Xr code looks
> like this:
>
>       XrState *xrs = XrCreate(xrs);
>       XrSetDrawable(xrs, drawable);
>
>       XrMoveTo(xrs, 10, 10);
>       XrCurveTo(xrs, 10.5, 20, 15, 20, 17, 18);
>
>       XrSetLineWidth(xrs, 1.2);
>       XrSetRGBColor(xrs, 1.0, 0.5, 0.2);
>       XrSetAlpha(xrs, 0.5);
>       XrStroke(xrs);
>
> You get the idea.

Yep. Karbon code :

m_painter->setPen( stroke );

m_painter->newPath();
m_painter->moveTo( KoPoint( STROKE_BOTTOMX + 1, STROKE_TOPY - 1 ) );
m_painter->lineTo( KoPoint( STROKE_BOTTOMX + 1, STROKE_BOTTOMY + 1 ) );
m_painter->lineTo( KoPoint( STROKE_TOPX - 1, STROKE_BOTTOMY + 1 ) );
m_painter->strokePath();

(from http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/karbon/)

> I took a look at QT once and it looked like porting its graphics to
> use Xr would be quite easy. Switching from libart code can be a bit
> more complicated, (since libart exposes a lot of internal data
> structures such as the SVP along with operators for these).

For KSVG we didnt hide them well, but for karbon we did. We have a PS
like painter API :

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/karbon/render/vkopainter.h?rev=1.32&content-type=text/x-cvsweb-markup

> Xr makes SVG implementation quite natural as it supports paths, text,
> and images. It also supports save/restore of all graphics state as
> well as push/pop of groups for grouped rendering as in SVG and
> PDF. I'll be coming up with a good solution for gradients soon, (my

Right, gradients can be tricky. For instance in boundingBoxMode it
requires an extra transform if the bounding box is not rectangular.
Its things like this one (or at least I do) misses when first reading the
specs...

> goal is that Xr should have basically everything that's in the PDF 1.4
> specification). And I'm having fun getting my little xsvg test program
> to work through the W3c SVG conformance suite. Progress is here:
>
>       http://keithp.com/~cworth/svg/conformance/

Looks very good. To my eyes, the AA quality looks about the same as
libarts, but I havent really investigated it.

> The fun part is that Xr tessellates all graphics into trapezoids which
> it passes off to the X server via the Render extension. At that point,
> the server rasterizes the trapezoids and does the translucent
> compositing. The huge win here, (aside from not shoving huge pixmaps
> down the wire), is that the server can take advantage of modern
> graphics processors to accelerate these operations.
---------------------------------------------------------------------------------

Hope this helps a little bit.
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/


Kde-cafe mailing list - Kde-cafe at ofb.biz
http://ofb.biz/lists/listinfo.cgi/kde-cafe

DISCLAIMER: The views expressed on this mailinglist are the personal
opinions of the author and do not represent KDE or the author's employer.