[GEM-dev] Maybe high-level wrappers around openGL wrappers for vector drawing? WAS Re: [Vektor] [RFC] intuitive idea

[B. Bogart]

Hi Dan,

Ok, this is good to here, sorry I just jumped in without seeing the
whole picture. Sounds like you are also proposing soe storage format in
XML for the vectors?

Actually you just inspired me to think about the possibility of a
collection of pd/gem abstractions for higher-level vector (2D) drawing,
all based around the gem OpenGL wrappers....

Right now in Gem the only way to draw a long spline curve without a
fixed number of control points is to directly use the openGL drawing
function, or to use a dynamic array of two point [curve] objects.

I'l looking forward to see what develops here.

How do you think the proposed system could be used in other applications?

.b.


daniel fischer wrote:
> "B. Bogart" <ben at ekran.org> (on Fri, 28 Oct 2005 15:01:28 -0400):
>
>   > Anyhow its just my strong opinion that a vector engine for real-time
>   > graphics should simply be built on openGL and not fabricated from scratch.
>
> hey ben,
>
> thanks for your comment.
>
> i don't think anyone here wants to build a vector engine from scratch. that would indeed be wasted time (we already have cairo's software renderer, antigrain, gl, mesa, and maybe more). and what you mention is basically what i try to do (SVG->OpenGL). i'd just prefer to be renderer-agnostic, both because of the problems with opengl you mentioned, and because sometimes it might be preferable to take a software renderer for quality reasons.
>
> cairo sports a gl-backend called "glitz". but i want to go even a step further, because what i described as "the renderer's model" (well, not described, but mentioned) can be implemented using OpenGL's DisplayLists, so then unchanged objects (even sub-objects whose parents change somewhat) will stay cached on the graphics card (at least with a good GL implementation).
>
> so, in fact, when i will go on about writing an actual renderer, it will be using gl pretty directly. which doesnt mean there's no place in this world for antigrain or other software renderers.
>
> maybe i should make one thing a bit clearer: i might make some statements about the renderer's design, but really what i'm trying to find is an interface specification to it. i'd definitely love it if there are multiple concurrent renderers.
>
> -dan
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20051029/4b9b69f4/attachment.pgp>