Re: Word attachment...on linuxtoday

[Lauris Kaplinski <lauris ximian com>]

Hello!

Agree 99%

Actually libart is already halfway there. The biggest problems
for me are:
- it lacks bezier path ops (clipping etc.)
- it allocates all arrays itself, instead of allowing to use
  prealloc stuff

Now, OpenGL is not very good example of generic library IMHO.
Ever seen/written any serious game via OpenGL - painful querying
of supported extensions, and painful hacks to avoid fallback
to software-only rendering. I am afraid something similar
happens, if you try to mix generic vector library with
hardware acceleration...

How IMHO things should be arranged:

a) Library of geometry (doing bez. clipping, advanced stroking,
   filtering on rgba buffers etc. etc.)

b) separate output-dependent rendering pipelines

Now, you cannot really make universal frontend to (b), at least
not with sufficent speed, because different rendering targets
need different prebuilt datatypes for optimum speed. For example:

To do RGBA rendering with libart (or libart like) library, you
eventually HAVE to use something SVP (sorted vector path) like,
and store SVP-s in client-side display cache. However advanced
is your output library - there will be cases, if you just have to 
manually control each and every pixel of shape...
For highly abstract OpenGL-like frontend, you definitely want to
use something bez. path, or vector path like. Display cache will
be no issue, as drawing bez path is fast anyways, and you only
want to cache paint servers and similar stuff.
Anyways, you have to deal with 2 different types of input for
different output targets. And using wrong one for either on
is HIGHLY inefficent.
Just look at OpenGL (Mesa) with hardware and software rendering
- due to single high-level API, application is unable to help
software-only rendering in any way.


So I would buy only (a), plus rendering stuff sharing common
datatypes, but I do not believe into common rendering library -
or, to be more precise - there can be one, but I do not think
it can be relied on graphic-intensive applications.

Best wishes,
Lauris Kaplinski

On Fri, 2002-01-18 at 03:44, Charles Iliya Krempeaux wrote:
> I'd imagine that we can find some kind of common ground for a 2D vector
> graphics library.
> 
> Something along the lines of OpenGL.
> 
> Maybe just an immediate-mode library for defining various kinds of 
> primitives.  Like line segments, ellipses, splines, etc.  And doing
> stuff like stroking, and filling.  Filters.  Etc.  Etc.  (Obviously
> it would be a big list!  I'll save writing it down in this message...
> unless anyone wants to hear it.)
> 
> Such a library would save everyone the trouble have having to do
> stuff like: writing their own Bezier curve clipping routines.
> Or writing their own anti-aliasing  stuff.  Etc.  Etc.
> 
> I think something like this could be useful for all applications.  And
> "drivers" for using hardware acceleration, could be written for this
> library.