World: r3wp

Maybe my understanding is wrong, and all api is done already?

VID shouldn't be affected. The host-kit change with the low-level 
part: VID | VIew | Rebol Core | AGG | OS. We need to implement all 
DRAW commands yet.

From the API point-of-view, VID should not be affected, but - if 
you don't have all draw commands implemented yet, it can't work yet, 
no?

Yep, that's why we need to implement them now.

OK, now I understand - I was just trying to understand, what is currently 
happening :-) Any ETA for the transition? 1 month, more? :-)

so we just have some primitives again?

This AGG stuff is pretty old ... has copyright from 2005

transition shouldn't affect GUI development. it's not like all copies 
of A97 stopped working. :-)

AGG 2.4 has the BSD license and 2.5 ( seems work stopped in 2007 
or before ) has the GPL license.

So, I guess we're stuck with 2.4 unless we can find something else

Graham - we use AGG 2.4, because with 2.5, Max changed license to 
GPL. But Cyphe said, that there is not much new in 2.5. AGG is a 
dead-end anyway - it is not further developed by original author 
(Max Shemanarev) imo, but still good.

So, what are the alternatives?

OpenGL

no, Cairo ... but AGG is still better than Cairo, so why to worry? 
And even if Max does not develop it further, maybe AGG community 
will come with some other improvements ...

We can enhance agg ourself, I guess.

so far we're not even taking 100% advantage of AGG, so there's a 
bit of juice left in it.

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.