World: r3wp

Yep, there are some interesting methods, like bounding_rect or so 
(to calculate the bounding coords of a shape)

rather than enhance AGG 2.4 .. why not move to OpenGL ?

We then get access to all the 3D stuff and physics models

I'm not sure openGL can cover what AGG does and vice versa.

so both are in a way relevant

Henrik, something really interesting would be a method to get back 
all the constructed vertices (after transformations).
As a shape block.

Don't know if I'm clear

I see AmigaOS4.1 uses cairo

Graham, yes, since Hyperion are so insistant on making AmigaOS look 
like any other linux that is of course what they would use.

Steeve, Cyphre probably understands that better than me, but I assume 
this means some level of hardware acceleration possibility of DRAW 
transformations. :-)

I see Cairo has both PS and PDF as output targets ... which sounds 
really good to me!

uh ?

http://cairographics.org/manual/cairo-ps-surface.html

The only thing Carl dislikes about AGG so far is that it's written 
in C++. This gives compiler issues.

Transformations are handled by matrix computations in AGG, how do 
you want to accelerate that and keep it portable ?

Steeve, ignore me. I just don't understand your original statement. 
Cyphre would understand it. :-)

Graham, I suspect Cairo takes on tasks other than rasterization, 
which is why it has PDF/PS outputs. AGG doesn't do that and shouldn't 
be doing that anyway.

Why not?

Henrik, I just think (in the contrary) that we could get back all 
the constructed vertices just before rasterization, in a plain rebol 
block.
So that we could output any format we want easly (PDF, PS)

Looks like it gives us access also to win32 printing

And it's C and not C++

Let's first get the thing up & running, than used to see what doesn't 
fit and than we think about enhance, re-factoring etc.

Remember that AGG has a neat design. All stages are pipelined and 
it's easly to interrupt it at any step.

*easy

Fighting at too many fronts at the same time is not a good idea.

Steeve, ok I see what you mean now.

Steeve, but this is still Cyphre territory :-)

Graham, size of the library could grow and we don't want that. But, 
Steeve's idea could circumvent that.

There really is only once place you need to be concerned about the 
library size and that's  for cgi .. and that doesn't use graphics

So I believe the concern about library size is misplaced

We're not in the embedded space, or on phones ...

Well, I disagree.

Rebol's run time memory far exceeds any savings we might get from 
a small library

That's not the issue. The issue is to avoid bringing in the hellish 
chaos of win32 printing so close to the rebol core.

so you want to go another decade without the ability to print??

There will be plenty of ability to print, but surely there are smarter 
ways to go about that than by bringing in a huge monolithic library 
like Cairo.

And the fact is, that most systems will be running the library anyway 
as part of firefox or something else

small is beautiful except when you can't do much with it

That doesn't help anything for platforms that don't use it.

that's what the host kit is for

As said, size is not the issue, but managability. The issue is to 
keep uniformity as far outward as possible in the rebol core. If 
possible, keep win32 printing as a small mezz library, like DocKimbel 
has done for R2.

(size is a side effect of managability)

How big is Cairo lib? IIRC it was over 1MB? I agree with Robert - 
let's finish what we have. Let's see, what enhancements we can get 
in. AGG is still a cool library, being used by MANY projects. Just 
becuase Mozilla honchos could not do any better and choosed Cairo 
as mostly a political decision (because of author's involvement in 
the project) does not mean Cairo is any better ...


Apart from that, and as Robert says - in future, we can eventually 
replace it.

I agree with not switching right now, but I also think we need to 
consider the benefits and how we mgith get PS/PDF support. I've though 
DIsplay Postscript was a great idea since NeXT. And if there's a 
way, for those who want to include it, to add it as an extension, 
we don't impact the core.

an extension linkin agg and  opengl would be awsome and crazy at 
same time
that's sad the developpement stopped

but there is 2 things differents ... you have the dialect draw wich 
gives access to the insertion of  drawn shapes into a VID face and 
AGG is the engine can then beanything
....

can opengl be  used the same extends as AGG hum ... opengl have a 
heavy mechanics and that's not suited in my opinion for 2D fast over 
face rendering

the thing is draw and so agg can be used on any widget  componing 
VID and that's a hugde constraint

what really sux with opengl are those  half assed IHM interface i 
know glut, x and w32 extension that allows the opengl rendering engine 
to recive user

events and then display  on screen in the particular area set for 
it.


Those interfaces are not 1% as fun as VID... Vid is total flexibility. 
we never did that in vid be you can imagine heavy animation using 
draw dialect on any kind

of preset styled face. I think carl tryed to show that with the animated 
sliding widget when you open a window in his R3 GUI demo.

for me doing 2D using opengl always apeared to me as using a nuclear 
bomb to kill a single poor tiny cute ant ...(ok ant isn't cute...)

that doesn't means it doesn"t have it's grace.