AltME groups: search

yes, its a BUG in AGG, using more than 2 values in line pattern will 
cause the crash.  its the oldest AGG bug I know of.


spoke with cyphre, its possible that this will be fixed in next release 
of R2, which shoudn't take more than a few weeks IMHO.

Ashley has some code that draws the buttons done in AGG.

are those AGG buttons??

He moved from bitmap buttons to AGG to try and save some ram.

when it comes to eye-candy, View, and all of it's GUI libs come in 
third at best

 ... I'd exclude View from that statement. With AGG support built-in 
 it enables you to be as creative as you want; the fact that no-one 
 has built a nice Konfabulator-like dialect that uses View to its 
 full potential is another issue.

 the fact that Konfabulator-like dialect that uses View to its full 
 potential is another issue.


did you look at (short on time, cause everyone else was late ;-) 
 elixir devcon session ?


that just what it is...  100% AGG gui engine... with full AGG element 
based interaction and per stroke feel.

AGG + Autofocus = Extra aliasing

AGG without a dialect? Might as well code in assembly, or openGL

HI, I'm new to Rebgui. Is it possible to use Draw or AGG in Rebgui 
personnal widgets ?

And my answer is it's not a RebGUI problem. Try the following code 
on 2.7.7.3.1 (Windows):

	view center-face make face [effect: [draw [text "xxx"]]]


You should see 3 black x's in the top left corner of a new window. 
Now try this on 2.7.7.2.5 (Mac) ... a blank window appears. I suspect 
the same thing happens on Linux. This is not a dialect problem (VID 
or RebGUI) but an issue with REBOL/View AGG font support on non-windows 
platforms.

Also note that while the following works on Windows:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "Verdana" size: 18]) text "xxx"]]]


path-qualifying the font name on Mac (and I suspect Linux) still 
does not work:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "/Library/Fonts/Verdana" size: 18]) text "xxx"]]]

MaxV, does this work for you ?  http://www.compkarori.com/vanilla/display/AGG

the difference in your render and SVG render is mainly the anti-aliasing, 
which is crisper in the svg renderer.... probably has a better algorythm 
setup than the one use by R3... this is probably manageable within 
AGG, but AFAIK there is no control for it within R3.

wahoo ... lot to read .. T___T  basically there is in Draw/AGG some 
limitations due to gradient  system and matrix translation bugs i 
don't know if they have been solved  since i pointed a them ...

My, my, my...


I think some features in SVG, are too much work to implement with 
Rebol.

1/ The "objectBoundingBox" units.

Which means, coordinates and lengths are ratio or percentages. 

And they are converted to real units depending of the bounding box 
of the shape on which they apply.
It's easy to calculate when the shapes are boxes or vectors. 

But when it comes with arcs or curves, it becomes a pain in the ass.


It's not a real problem because Inkscape for example has an option 
(simplify shapes) to convert all the ratio units in real units (ie. 
pixel units).

So, I don't see the interest to rewrite DRAW from scratch with Rebol.

(because it's what it means, to be able to calculate all the bounding 
box)

2/ Outlines with gradients


Those fullishs can specify a gradient for the pen attribute (which 
draw the outlines).
Rebol can only have a gradient to fill a shape.
It can be simulated by drawing the related shape 2 times.
1 time with the pen gradient.

A second time with the fill-pen attribute (which can be a gradient 
too).

But the second time the shape must be, at first, downsized of the 
line width.

To do so, it means that we need to know the center of the Bounding 
box of the shape.
So, same problem than 1/


3/ The fill-pen attribute (gradient or color) never apply on the 
outline of the shape, event if the outline has no color but actually 
has a width.

It allows SVG for example, to have transparent outlines.
We can't do that with Rebol. 

Because the fill-pen attributes (or the gradient) fills all the shape 
at first.
And then the outline is drawed over.

If we don't provide a pen color, or we provide a transparent color, 
we see the fill-pen content instead, at the place of the outline.


Perhaps, that can be modified in Draw. A nice request but not a so 
considerable feature to my mind.

(And it can be impossible to implement this in Draw, if AGG doesn't 
support it at first).

re 1/

yes, I don't think this is a problem of DRAW but more problem of 
unit conversion. DRAW works with pixels as it it low level dialect 
(not only for rendering SVG format). So the higher level code(SVG 
parser) should be responsible for this until I am missing something.


re 2/ gradients for outlines were planned for addition so I hope 
this will be in the R3 final release ;-)


re 3/ transparent outlines are known problem. (BTW is this working 
properly in other SVG renderers? I'd like to see the results) This 
is because we are using rasterizer which is drawing one shape over 
another. IMO solution could be to replace the rasterizer with different 
one (for example like Flash) which is simulating 'Constructive Solid 
Geometry'.

But this would need major changes in the current internal implementation 
(and in fact also switch to higher version of AGG). 

My guess is it could also speed-up the rendering in some cases...I 
started to investigate this area but it needs more time which I currently 
don't have :-/

re 1/

Well you're right, it's the responsability of the client (parser) 
to do unit conversions.

But to do so, we need to know where the renderer draw each pixel 
(i mean the real coordinates) of a given shape, to calculate the 
bounding box.

Take an arc for example, it's impossible to calculate where the pixels 
of the arcs are drawn without simulating the complete AGG engine.

There may be various transformations to apply on that calculation 
(matrix, translation, scaling, rotation, skewing).
To calculate that, we have to simulate exactly what AGG is doing.

Mission impossible

my idea for draw elements was to allow set words in the draw dialect, 
and then be able to interact with the strokes rather than the whole 
block... since the conversion to/from AGG-REBOL doesn't need to be 
done all the time, some time is spared.  most of the time, we only 
need the dialect to create stuff... then, we can just manipulate 
it.

also it would allow us to get information about the strokes   

ex:   [s: spline 50x50 100x100 30x4]  

print s/length?  ; get spline length, in pixels

print s/coord-at-length 45 ; get coordinate at 45 pixels down the 
spline.

Maxim, yes, I think this is one fo the ideas we discussed at DevCon 
in Paris.

If we add the DRAW shape->coordinates interface this will be yet 
another usage of it.

The current internal architecture already counts with sort of persistency. 
Currently we are just discarding all the internal shape paths on 
every redraw. I fear the main problem is how to handle this efficiently 
at the REBOL layer, especially GC handling...it can lead to big memory 
consumption in case programmer won't free all references to the DRAW 
elements etc. Or maybe a command for manually edstroying the 'DRAW 
internal context' would be the best solution...

Another question is, even if we solve the REBOL high-level access 
interface to it, how much would direct DRAW element modification 
at such internal level affect the performance, is it really worth 
doing that(ie make things more complex)?

Because in that case we will be only 'bypassing' the DELECT parser 
and AGG's internal Coordinate conversion pieline(s)...the rasterizing/rendering 
pahse needs to be always redone(but we could try to play with some 
clipping tricks here too). Both parts are already very fast but I 
agree there can be gain in some large data cases. This needs to be 
investigated before we decide to add such feature.

with two splines and enough information gathering, we can easily 
render bending geometry and stuff like that... right now... its highly 
complex, and we can use the internal AGG binary math to calculate 
all the coordinates to stuff for us... based on the current transforms, 
and stuff.

Dunno - there can be many various requests, but basically it would 
be correct, although we do have Effect pipeline too, but I don't 
know, if it is AGG based, or not ....

AGG is not only about draw - it is our rendering engine too ...

Not necessarily.  If using AGG fonts, I want to know where I am so 
I can calculate how much space I have left on a line.

there is 2 ways to see a window and it's content the first 1 is the 
all made container the window is a set of default widget a tittle 
a status bar etc.... or you see it as a transparent rectangular area 
where you put other common widget . Maybe the true power of VID2 
 and by extention the true power of the rebol dialecting would be 
to think the window as a transparent rectangular area and then have 
2 kind of super widget able to get user input and deal with event 
able  to render draw AGG instruction and this widget will be the 
base for a design of all the widget

ICarii yes but that always been the case hihihihihi .... I remember 
rebo 1.3 .... Mwuhahahaha  full amator dev .... oups sorry. So it 
first start as 1.3 is only solving the loooooooooooooot of bugs posted 
on rambo by the community then it turns to Ho and how about adding 
AGG  to ViD ? and then it was Hey I  have a big new thing REbSERVICE 
!!!! and ASync  .... Bhuuuuuuuuuuuuuuuuu

but who can deny that AGG or async or rebservice are cool stuffs

Things i would like to see completed in R3:
1. AGG/Draw and richtext fixed.
2. Ports/async working 100% reliably.
3. Object system global/local completed.

unfortunately all these areas are currently a black box scenario.

I love AGG. but seems we don't do enough.  Like why not REBCODE integrated 
with the latest release?

AGG/Draw in R3 is very powerful - but view limitations (transparent 
surfaces etc) seem to hold it back.  Again - rendering to an OpenGL 
surface might solve some of these issues?

you could do transparent buttons (hum that's partly false  you can 
do that if you draw your button using AGG  then you use mouse position 
when  left clic is done to simulate the reaction of your button) 
or windows

http://www.rebol.net/wiki/GUI_Note_-_Shapes_in_DRAW_Blocks- I think 
that we should be aiming at graph based low level AGG based design, 
with the ability to cache various nodes. IIRC Cyphre was talking 
about something like that, but not sure it is implemented ... good 
that such low level things are explained though ...

A bit of status:


- Carl ran into a bug in the AGG C++ code: "draw 10x10 []" in the 
console will crash R3 and it's a tough one, as it might be compiler 
related. Not fixed yet.

- Some of the stuff that BrianH has talked about above is now implemented 
in a new build of R3 as well as some additions to MAP!.

- My ramblings on DRAW has caused me to pause on skinning until I 
can get a clear picture of whether the problems will be fixed. Otherwise 
I'll have to redo a lot of work later on. I experiment with compound 
styles instead as well as some simple color palette tools.

- It was decided that popup graphic elements are to be done in separate 
windows for greatest flexibility. No code done yet though.
- No talk about overlays or drag'n'drop yet.

I hope we can improve the font antialiasing. I know AGG allows many 
more tricks with fonts than we can see.

Paul - there is more to the View engine. It is sometimes reported 
being 10 or more times being faster. Whole R2 View compositing engine 
was scrapped, and replaced by AGG one. AGG is our main engine now 
...

I really hope so. I believe AGG offers a lot of font hinting options 
that we are not using at all.

oh, seems like AGG is really a cool engine. So we are not utilising 
it full-force, right?

The above font rendering article is great work, but unfinished. It 
requires further work on both AGG and FreeType

(The AGG site, that is)

Status of AGG is not good for us. First, - we are using AGG 2.4, 
which was really free. From AGG 2.5, it changed to GPL, and as we 
know, GPL sux :-)

Currently AGG is at version 2.6 IIRC. It is not much developed, as 
Maxim Shemanarev (author) took some job oportunity.

AGG is still at 2.5, a bugfix release. He never got as far as 2.6 
and hasn't updated in 2+ years.

pity AGG is no more developed. There is no other option currently. 
Everybody else uses Cairo, but this is crap with more than 1MB size. 
Amanith seems interesting too, but commercial. Hopefully Maxim updates 
AGG at least to keep the trends. But so far - AGG is very high quality, 
so nothing to worry about for quite some time....

The reason why he is not much active in AGG land is, that he already 
took some job.

I suspect the answer to whether hardware acceleration will be provided 
will depend on whether AGG supports it. (I think not).

AdrianS: talked with Cyphre xy times. AGG does not support HW acceleration 
out of the box. But Cyphre plans to add it. Either as regular release, 
or as his own commercial project. Remember - whole View is going 
to be open-sourced. After all - it is mainly an AGG code plus events. 
There is a little bit problem with HW acceleration though - that 
stuff is not 100% compatible amongst the platforms - you might not 
get 100% pixel precise rendering ...

It's funny that Maxim changed AGG to GPL for new development, then 
didn't do any.

AGG Versions: I really don't understand why Carl is not asking for 
a Rebol license? I'm doing this quite often for GPLed stuff and it's 
not big deal. Most authors are proud if what they have done and just 
want to avoid that the dark side is using their code.

Robert, I think that a good reason why Carl hasn't asked for a REBOL 
license for the AGG 2.5 is that the license is the only difference 
between it and 2.4 so far, and further development of the GPL'ed 
version seems to have stopped there. :(

Actually, we may be wrong in one of our assumptions: REBOL may *already* 
have a commercial license for AGG. Carl hasn't said anything to the 
contrary, just that it was "no problem" when the subject was brought 
up years ago.

should be simple enough - there are only a few text changes in R3 
Draw/AGG

Just two questions - 1) what it the space at the bottom grid? A layout 
bug? Or just wrongly set container size? 2) Will there be anything 
done to font rendering? Some letters look rather blurry. Is it a 
bug, or just we are not still using more advanced font rendering 
techniques? I thought that moving to AGG will solve it for us ...

I guess that in AGG you just must call unicode functions of the api. 
But I really don't know details. But the unicode in gui must be, 
else the changes in core were useles.

yess I did, but in this case, the goal is to do interactive AGG manipulation 
of one image at a time and stamp it on a layered composition.  by 
the time I load the third image (from a digital camera at 7.1 MPixel), 
rebol crashes  :-(

it was probably related to using the image in view or AGG specifically, 
or maybe specifically to using a png format image.

Maxim - try asking Cyphre - he is now our low level gfx guru. He 
might know, how it is implemented. Also - with R3, entire compositing 
engine is replaced by AGG one.

C and REBOL, with some C++ in linked libraries (AGG).

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

its 2003 - back before the text in agg changed

Do we have a deeper text compositing support in AGG ? (woops...)

Steeve - just a simple way to get font-metrics for layout planning 
where you cannot rely on richtext in AGG working (eg it doesnt wrap, 
doesnt do bounds in Draw mode)

Another reason im interested in AGG richtext (as opposed to text 
gobs) is that i'm intending to use OpenGL rather than rebol rendering 
once the plugin architecture is finalised.

Shadwolf - I am not blaming anyone. Font ugliness has something in 
common with font hinting. Cyphre told me, that such code in AGG is 
licensed (or patented?), and that we will have to find some other 
way around. But you would have to ask Cyphre, I don't remember exactly 
what was the reason ...

Pekr > you said we need to find a better way to handle fonts in AGG 
cause part of it was pattented (or OSE related) and i sugested GTK+ 
 with is os independent and GPL 2.0 (pango is a heavy but really 
complete way to handly richt text rendering )

well i imagine that since the TDM (Text  Dialect Markup ) exists 
than AGG will follow and offer brand new things to handle conveniently 
the texte (and please please forget once for all about teh caret 
system please i beg you T___T)

Mostly C, though AGG is written in C++.

Max - I think it is C, although AGG is C++

although liquid-paint is already much faster than AGG and lazy so 
the gains might not be as noticeable, but still I can't wait to have 
time to try and port my stuff to R3, it does seem to be much more 
series stable, by all accounts.

Henrik - a bit OT here, but maybe not. Have you looked into UIs of 
iPhone, HTC Sense (TouchFlo 3D)? I wonder if those glossy nice icons 
and other UI elements can be done using AGG and gradients, or are 
those things precisely rendered using 3D tools? Or are they just 
non-scallable bitmaps?

with extensions all of the View internals can be outside... its basically 
AGG with a set of predefined hooks.  The only detail would be custom 
datatype... which should eventually reach extensions... maybe Carl 
could just build a special (undocumented) extension hook so that 
cyphre has access to more stuff, without the hassle of supporting 
it as a feature for the public.

3D allows us to use sub-pixel rendering which is actually more precise 
than AGG.  and if you don't use fancy shaders and effects, the rendering 
will be sooo similar as to not even be measurably different.

I will correct my previous statement... AGG can do sub-pixel stuff 
too... but our use of integer pair! datatypes limit us to pixel coordinates 
within view.

as brianH noted yesterday using freetype has some licensing issues 
which might not provide the best looking fonts when compared to OS 
rendered fonts.  but maybe AGG could render the fonts with coordinates 
given by freetype.

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

font rendering not taking advantage of AGG i'm completly agree since 
anti aliased doesn't works properly but this should be the time on 
that particular area to see the font rendering area under a new line 
of real time text processing and their is alot  of amazing things 
to be done . 

in the end my request is simple i want my users to choose their own 
font they like on any ot the main OS brands and get the same result 
everywhere (even on online editing for example imagine the rebol.org 
integrating viva-rebol thrue rebol3 webrowser plugin  to allow the 
script sumiters and owner to share editing of a script with bunch 
of select people. That's the qualité we should aim for.)

but yes I would say R2 lasted too long ... carl was glued in endlessly 
bug correction and few where the real improvements... the major addition 
in R2  was the AGG/draw dialect which since then have not evolved 
a bit... look at the number of tickets in old rambo. So yes starting 
with a ew base and bring alot of enhancement was a certain thing 
the problem is along the process we lost alot of people mainly interrested 
in rebol but not seeing it evolving fast anough and that how do you 
solve it ?

actually, REBOL is fast enough... its the R2 integration to AGG is 
which is quite poor.

cyphre... use this as a basis:


view layout [box 200x200 effect [
    draw [
        push [
            translate 119x119 
            pen none 
            fill-pen black 
            box -50x-30 50x50 
            fill-pen blue 
            pen red 
            line-width 3 
            circle 50x50 25 
            fill-pen red 
            pen blue 
            circle -50x50 25 
            fill-pen blue 
            pen red 
            circle -50x-30 25 
            fill-pen red 
            pen blue 
            circle 50x-30 25
        ]
    ]
]]


adding new black, red, blue, black, circles in betwen colors may 
give very poor results.  sometimes 1 pixel width lines practically 
disapear horizontally!


playing around with the line width will also have a different visual 
impact, since the aliasing will spread the error more or less.


as I said, i know part of the issue is related to the screen's rgb 
sub-pixel channel components but I remember trying some of this in 
other softwares and the effects weren't as image degrading.


to me the main defect is that you will notice a WHITE ringing effect 
between the red and blue on one side and a black ring on the other.


I can understand the black ring, but can't explain the white one, 
which is why I think it coule be related to gamma issues.


also, the black ring seems to be wider than it should &  the effect 
seems the most apparent at ODD line widths, which is a bit strange 
too...


I'm wondering if AGG has an algorithm which is trying to compensate 
for pixel to pixel color defects and gets it wrong.  


maybe it could be enhanced to support subpixel aliasing (or gets 
it wrong if it already does so).

Max, I'm sorry I don't see any degrading 'ringing effect' when looking 
at your example. Even while looking at scaled screenshot the AA of 
the edges of circles looks perfectly symetric to me(did horizontal 
flip comparisons). I'm using average LCD display and also my eyes 
are getting older every day so I still might missing something.

AFAIK AGG is not using any 'compensation' code. It simply computes 
the covers of every pixel cell using 256 levels and ofcourse uses 
subpixel AA(try to translate by fractions of pixel..). So the AA 
result is still very high-quality(though there are very few special 
cases limitations of the used alogrithm). If you compare it to current 
FSAA abilities of gfx cards 256 levels is still way more than what 
the current  super/multisampling offers.

I'm working on isometric rendering of 3 polygonal gfx in AGG, so 
profiling is currently quite high on my list   :-)

Do you use the skew command in draw ? or are you calculating the 
coordinates of your 3D objects for each layer.

(I think SKEW allow to simulate isometric rendering in AGG, but it's 
just an assumption, i never tried it)

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

fixing bugs and getting control over AGG.

As it looks, due to the efficiency issues (speed), the implementation 
of REBOL pairs as pairs of floats looks to be the fastest (since 
AGG needs double values, and conversion from float to double is faster 
than conversion from integer subpixel count to double using a foating 
point division looks slow)

Ladislav, you need to put the AGG implementation considerations on 
that page. The page currently looks like you are advocating using 
48bit integers, not floats.

Anton, there would be no memory savings by using 48x48 integers. 
The pair would still be in a value slot, and value slots are fixed 
size. And they would be slower to access because of alignment issues, 
plus the floating point multiply to convert them to the doubles used 
internally in AGG. "So it looks like 128bits are available." - only 
on 64bit builds of R3, not on the 32bit builds we have now.

We can upgrade to doubles in the future, in the 64bit builds - AGG 
uses them already. Though I don't know the effects that would have 
on rounding and such.

An extension like AGG, which also uses doubles. But we can't fit 
two doubles in a value slot on a 32bit build, sorry.

There is a new command block evaluator that needs to be used a bit 
differently. Hence the DRAW dialect loop needs to be adjusted. As 
the AGG interface

Update: The go.r test code is now running properly in A101 with the 
fully converted PAIR datatype and changes to the AGG API to accept 
both pairs and gobs using float values.


It turns out that because AGG wants floats for most spatial values 
anyway, the PAIR change makes the code smaller and faster.


Certainly more can be done to minimize the interface to AGG now (removing 
the double trampoline within the API) but that's a project for Cyphre 
when he returns from the islands ;)

Thanks Carl.
Though for AGG, I don't expect a lot (in term of speed gain).

IMHO, the main overhead comes from the involved arithmetic using 
floating point decimals.
Matrix computations are costly with floating numbers.

But The final rasterization uses fixed point decimals and floats 
could have been avoided, i guess.
So maybe there is a major room improvement here.

CARL ONE ASK CAN AGG   BE MERGED WITH AMD/ATI OPEN CL Technology 
? ( some thing like a background application that would detect what 
hardware you have and use multi hardware CPUs GPUs to run those expensive 
task. Once again  what in rebol can be an very expensive task .... 
answer a state of art webbrowser rendering engine with flash silverlight 
support....  IF we can bring rebol to that state i think no one will 
look at it as a toy ... then the question is way doing a webbrowser 
in rebol ?  REply is because i love rebol :). But on a ground level 
if you want to enter in competition with the other languages and 
prove the interrest of the rebol method then you have to be able 
to do what the others can do )


This open CL adition can too benefits non graphical applications 
i don't know how but  why not saying look rbeol is not dead it's 
the futur and as the futur it provides the best way to use the futurs 
technology. And that's a field none of hte interpreted languages 
now in day have done ...

since then a lot have been done altme could use a agg rendering method 
insteas of a VID face concatenation etc...

AGG is not the best place to put OpenCL support. OpenCL is not very 
useful for accelerating graphics, and that is what AGG would need. 
A standalone OpenCL dialect would be more useful. Graphics acceleration 
uses other APIs, like OpenGL or Direct2D. AGG isn't 3D, so using 
OpenGL or Direct3D would be equivalent to reimplementing Direct2D 
on platforms that don't support it.

Brianh hum actually when i we display things using agg the cu is 
used only and if we want to do extensive computing visual effects 
like zoom spining things etc ... hten the cpu will be extensively 
used ... and since rebol doesn"t take advantage of  multi CPU  or 
CPU <- to ->GPU communication then the extensive computation loops 
are not enhanced. Problem is now in day NVIDIA is so expensiv no 
one buy it  10 ATi cards are sold for 1 nvidia card and in a very 
near future AMD CPU will be mixed with ATI GPU  into a single chip 
(APU fusion). This is the tendency of the computing area so if you 
have to support 1 paralelle design i would go for the AMD /ATI  couple 
instead of  betting on a close to death horse...

As for seeing a partial pixel, the writer of AGG demonstrated (in 
an unrelated post) using anti-aliasing to do 1/256 horizontal pixel 
positioning.

Tools for graphics too, which others are actively working on now. 
And once AGG is reliably in the host then the whole (qualified portion 
of) the community can work on optimizing it.

and redering a text only document is not the same as rendering a 
web page for example ... we are one step closer to that goal when 
i proposed a AGG only engine people told me it's impossible and steeve 
made that vision come true ...

ok another question i know i'm a bother ... but if  us tiny bunch 
of crazy fans we don't ask us silly asks we will never get steps 
further and get rebol writed in history. So the crazy is is why not 
doing rebol in java instead of C or C++ ?


I mean now in days having rebol based on java what are the possible 
gains ?

1) Easier way to handle multiplateform

2) Big big java comunity and so getting strong specialised people 
to enhance rebol VM will be easier.
3) no need to adapt algorithms across plateform.
4) all the curent technologies are adapted to java. 

the bad points are:


1) jre weights alot and rebol being based on it will not be stand 
alone so it will need the jre to be installed to run
2) goodbye AGG 
3) interfacing with java libraries can be problematic.

I think the good points overcome the bad points.

Basing some REBOL-related tools on Silverlight and/or the DLR would 
be a plus. Keep in mind that we don't have to make the whole of REBOL 
run within the JVM or DLR - REBOL is great for making development 
tools, which can be used to generate Silverlight applications, just 
like they generate Flash applications. Or R3 could be used as a library 
by Java, or as a supplemental developemtn tool, or a code generator, 
whatever. Remember, most of REBOL is a set of awesome libraries and 
dialects. REBOL without most of DO or AGG is still useful.

brianh right ... to the problem can rebol display formated dynamic 
text using Draw/agg dialect it only took me a steeve and 3 yeart 
to apport the solution ... and lot of discutions ...