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

List:       xfree-render
Subject:    Re: [Render] Small Xr example
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-12-01 20:04:59
[Download RAW message or body]

On Sunday 01 December 2002 10:17 pm, Owen Taylor wrote:
|  Vadim Plessky <lucy-ples@mtu-net.ru> writes:
[...]
|  > |  I don't think they are ready for Rawhide -- rawhide can be quite raw,
|  > | but it's also stuff that we think is going to be ready for the next
|  > | release; Once they settle down a bit more, I can look at making
|  > | unofficial RPMS... the main prerequisite there is a tarball and a
|  > | version number scheme.
|  >
|  > Do you think Xr/Xc wouldn't be ready for your next release?
|  > I hope it should be ready pretty soon :-)
|  > We need good groundbase for SVG rendering on X, and Xr/Xc looks like a
|  > perfect candidate for this task.
|
|  Well, before a library would be considered for inclusion in Red Hat:
|
|   - There would have to be some serious application of the library
|     to demonstrate that it actually meets the purposes it was
|     desired for.

this is quite understandable.

|
|   - (Usually) something else in the distribution would need to require
|     it. The supported devel platform for Red Hat is a small subset
|     of the libraries we ship as dependencies of apps.
|
|   - The authors of the library would have to express confidence that
|     the ABI/API of the library is something that will be supported
|     long term.

Agree with both statements, too.

|
|  None of these are there yet for Xr/Xc. I suspect Xr/Xc can progress
|  quickly, but putting it into a distribution prematurely wouldn't
|  help.
|
|  If someone wants to use Xr/Xc for a SVG renderer, then they need to
|  try writing their SVG renderer and figure out what's missing. There
|  are some pretty obvious gaps currently. (Like the ability to render
|  and get access to the pixels client side, which you need for SVG
|  filters.)

well, AFAIK Carl Worth took librsvg2 (used in GNOME2 by Nautilus and Eye of 
Gnome) and decided to port it to Xr/Xc (to check rendering capabilities of 
those extensions). And, according to him, this resulted in almost complete 
code re-write, and new library - libxrsvg.
Still, apps which use librsvg (in particular - EoG and Nautilus2) can be 
rather easily ported to libxrsvg.
And there was alos suggestion/ide to port librsvg2 itself from libart to 
Xr/Xc.
I don't know wether some work is going in this direction, though.

So, current dependency list for , say, Nautilus:
  Nautilus <- librsvg2 <- libart
can become 
 Nautilus <- (new) librsvg2 <- Xr/Xc

If Xr/Xc is hardware accelerated (on some graphics adapters), than users would 
immediately get better rendering speed (and same rendering quality, not sure 
that it would better but I don't see any degradation over libart so far)

On the other hand, Karbon14 (vector-drawing application in KOffice) uses 
libart, too.
Dependency here is something like this:

 Karbon14  <-  VPainter API <- libart
which can become 
  Karbon14  <-  VPainter API <- Xr/Xc
(VPainter needs to be ported from libart to Xr/Xc)

Than we get The One World very close to being perfect: single enhancement to 
Xr/Xc/libxrsvg would result in enhancement for a lot of Linux/Xfree86 apps, 
running on rather different platforms: GNOME and KDE. Plus pure X apps would 
be able to use such SVG renderer/PS-like API, too.
Isn't this great ? :-)

|
|  Regards,
|                                          Owen
|  _______________________________________________
|  Render mailing list
|  Render@XFree86.Org
|  http://XFree86.Org/mailman/listinfo/render

-- 

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/
_______________________________________________
Render mailing list
Render@XFree86.Org
http://XFree86.Org/mailman/listinfo/render
[prev in list] [next in list] [prev in thread] [next in thread]