AltME groups: search

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

It will seamleslly integrate to my Custom Gob Renderer so the same 
GLASS style will be able to render in any renderer for which a compatible 
style was built.   


this means the same layout and interface for a button will be useable 
in a normal AGG render up to a 3D game representation of that button, 
with no user code change.  just a swap in the skin being used.

something like REBOL3! low-level gfx  could be ok,

note this isn't about discussing how to use view or a gui.


this really is for talking about rendering, graphic pipelines, agg 
C code, gfx engines, CGRs, stuff like that.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

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 digged following from Max in the past:
---------------------------------

My pet peeve about R3 view is that we still don't have access to 
the actual AGG elements directly within rebol.

We still have to go through a clumsy interface called draw dialect.

The dialect is fine (great actually) for initialisation, but after 
that, its not adapted to actual manipulation of what is going on 
inside, you have to go trough a rebol -> agg convertion stage at 
each refresh.

It's not the speed, it's the fact that it's complicated cause you 
have to create "virtual" draw components and then assemble them on 
the fly reducing blocks and stuff.
I'd love to be able to do:

a: draw [circle 30x30 15]
a/radius: 30
a/offset: 100x100
show a


If graphic elements where first class datatypes, we could completely 
ignore the gobs, and build real canvases, uber fast.

Another example, more appropriate:

; this draws a box...
draw [s: polygon 10x10  30x10 30x-30 10x-30]

; make it a house outline
insert at s/vertices 4 20x-40

; raise the "roof" 
s/vertices/4/y: -50


The problem is that to edit draw blocks, you have to create a slew 
of things before creating the draw block, then you have to store 
references to all of those things somewhere, everytime you want to 
add a "dynamic" attribute its pretty tedious.

The first-class gel datatype would allow AGG to edit its internals 
directly using binary C code through its accessors.  no need to go 
through rebol funcs and reducing blocks, etc.

The use of  "show a" above could intrinsincally know that it only 
needs to refresh the region that this element affects, just like 
all graphic cards do when evaluating the graphic pipe rendering.

So many things like flash games which become soooo heavy in AGG would 
be real-time and use much less CPU resouces.  in most games only 
a small part of the canvas really changes interactively.

Max continuead a bit:
----------------------

part of what I want to attempt for my host code work is to implement 
liquid and globs natively in R3.  with access to AGG I could build 
the single most powerfull canvas engine in any language...


 we'd have absolutely nothing to envy to ANY other language, not even 
 Apple's engine... as long as the AGG can render a few more things 
 and add filters to AGG strokes.


globs use AGG and allow events to be sent to individual AGG strokes. 
 so you can "slide" a single line by clicking on it. the cool thing 
is that the input mask and display are separate... and you can implement 
any number of layers per display element that you want.

I would assume that would simply be an extension of the rich text 
dialect and exposing more options from the AGG font renderer:

[hint 1 "abc" hint 0.8 "def" hint 2 "ghi"]

Pavel, yes, you are right. We switched the terms in the discussion 
above. I've been  mainly refering to this informaiton: http://en.wikipedia.org/wiki/TrueType#Hinting_language


AGG have kind of font manager module. The font manager basically 
takes vectorial glyph data (which are provided by Win API or FreeType 
lib, quartz etc.) then the glyphs are converted to scanlines and 
stored in font cache...

So this way we are depending on the vector glyph data provided by 
platform specific font frameworks.

The problem lies in the fact the hinting language(see link above) 
is patented by Apple so it is not possible to get the correct font 
glyph data without breaking the patents (or paying Apple).

That's the reason why fonts on Linux or FreeType based platforms 
can't look so nicely hinted as on Windows/OSX.

cyohre i noticed the glyph engine years ago in AGG C++ version and 
i asked at that time why that wasn't existing in view adaptation

1) it's possible for AGG to deal text rendering evolved at a low 
level (perf are great  on R2 and that's convincing)

2) Since draw wasn't made to handle such an extensive use of the 
draw/text instruction  in R3 we have to make the AGG mode adapted 
to block of text handelling the first idea and the main  boring thing 
to have to deal in AGG text rendering is the positioning of every 
block of text. We need a way to retrieve the position of a texte 
on screen.  

3) to be better and faster AGG should be less verbose. I know that 
it's possible to save lot of space in the draw block

IMHO, Henrik has stepped up as project manager for R3VID.  Cyphre 
is still interested in helping out on the low-level AGG AFAIK.   
Others, like me, will definitely chime-in when it starts being more 
organized, if only to implement Styles, themes and stuff like that.


But we need the next host released... and AFAICT, that is one of 
the main projects of Carl right now.  At least, I hope it is.

Cyphre is down with the flu right now and a sporadic internet connection 
due to snow, so I have no immediate status of what he's doing, other 
than waiting for the host kit, but what he's shown me, based on a 
separate AGG build, shows that there are a lot of ideas for what 
to do.

some two or more weeks ago he told me he is working on some demo, 
showing some AGG capabilities. That is probably stuff you saw? Will 
it be demoed? :-) Or is it just internal build to have some ground 
for further architecture improvement talks?

He was testing the bottleneck for parsing and drawing DRAW blocks 
as quickly as possible, and he calculated that the bottleneck for 
PARSE was much lower than that for AGG's draw routines, so it didn't 
make much sense to have to avoid PARSE according to his measurements. 
It might still become possible anyway to bypass PARSE, but I'm not 
sure.

The separate AGG build is just there until he can get a hold of the 
host kit and to test ideas.

in my soon to be released application, the dataflow aspect of the 
code is less than 20% of the time spent, yet it represents at least 
80% of the actual usefull software capabilities.  


most of it was fixing View and VID themselves... the styles, the 
event mechanism and bugs, AGG bugs, enhancing http, etc.

an example of a very complex system which was made 100% robust is 
this:

-an image is used as a background, cropped , transformed and displayed 
within AGG

-we need to overlay an text area over the canvas, but its all AGG 
and its contained within a graphic element.

-we create a face which is a text-area, LINK it to the coordinates 
of the graphic element.

-the face is then converted to an image on the fly everytime the 
coordinates change (even rebuilding the text wrapping interactively)

-this image is added at the proper position with the AGG draw block 
as an image with coordinates.

its why I'm pushing for graphic element as a lower-level api for 
AGG right into view.

but since the data is stuff I create, I can't READ the data which 
is being managed by AGG.  which would be the major benefit of  "draw 
elements"

Maxim, with this system you can easily manage any draw element or 
group of draw elements inside draw block.

I have been thinking about this and I don't see any benefit being 
able to access the data at the level of internal AGG structure. Rather 
it looks like it would make the whole system more complex.

The only thing which could be useful is being able to 'cache' already 
parsed DRAW block. That change can be done without much complications. 
But I should also mention that the 'parsing phase' is very little 
part of the performance overhead so cahing the internal structure 
would be theoretically useful only for really big DRAW blocks with 
tens of thousands and more elements..but such big blocks would be 
still not much usable becuase of the final performance of the rasterizing/rendering 
phase in such case.

But I'm still open and I'd like to know your clarification and explanation 
of the benefits you see in your requested feature though.

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

So you want kind of API access to low level AGG engine elements? 
Kind of like Extensions can access REBOL dtypes?

as I said, I will wait for the hostkit with view to be released before 
spending to much time on this... I really don't have time to go in 
depth with this... and I'm not even trying to convince anyone.  just 
replying to questions and I feel its being taken too seriously for 
now.   its possible, the better approach will be to have access to 
some of the AGG internals via the extensions and wrap these into 
generic objects, for example.


its still just an idea.  there is no point to going into details. 
 I need to see the view host kit first.

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

 AGG group about a bug in TRANSLATE

. henrik not a news that bu exist since 3 years i submited it long 
time ago when i was implementing matrix translation in AGG when i 
was writing SVG renderer. So far no one seemed to care about that...

( and on tooltip using AGG some cool effect can be done there ... 
 ( like a progressive fade away in time) )

Not sure we can make a discussion out of it, so I'm posting here: 
How closely related would AGG/Draw be with HTML5 canvas?

didec windows console is boring and ugly now that i show agg could 
deal  pretty stuffs with text in color why don't we HTMLize our console 
and bring some new way to experience console direct code flow coding 
cause that was the strong point of R2 and that's the actual weak 
point of r3

the developer states that his technique gives better results than 
Cairo and AGG

Well, AGG is good enough imo. Our problems imo lay elsewhere - GUI 
incompletness, GUI look (skin).

The morphic AA looks nicer though I wouldn't see any big difference 
if the pictures were shown separately to me. Also I haven't found 
any details..just couple of screenshot comparions with Inkscape. 
The author is not mentioning a word about preformance etc. As Pekr 
said AGG have already good quality and imo there will be 'slight' 
visual difference between Morphic unless you start comparing pixels.

Also don't forget there is not only antialiasing in play. AGG uses 
very vell written vector graphic 'framework' packed with features. 
All the new algorithms presented in recent years are still missing 
that part.

But I agree. If Morphic(or whatever else) will offer faster&better 
quality AA it should be possible to write custom rasterizer/renderer 
module(simmilar as the special Flash rasterizer) so it can be used 
inside AGG framework.

The issue with AGG font rendering is that we are not using the 'clear 
type' like techinque yet. It would look much better even with current 
AA. I believe it will be part of R3 once HostKit is avaliable.

(regardless of AGG)

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

AGG interface is speeded up. Current gain about 280% faster. As you 
can see the drawing time is about 3 times the resizing time. These 
numbers should become more equal.

Is the AGG cache an enhancement ?

*AGG cache stack

i hope with the cash we tends to a more extensive use of AGG and 
a less anecdotic use of this marvelous fantastic powerfull tool (aGG)

Some resulting exes:

07/10/2010  12:45 PM           267,776 r3.exe
07/10/2010  12:46 PM            28,672 r3core.exe
07/10/2010  12:34 PM           393,216 r3lib.dll

You can build an R3/Core without AGG.

For example: If you can't get AGG to work, you need to do a replacement 
with an equal API layer.

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.

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

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

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.

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.

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

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

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 ?

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.

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

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.

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.

ofcourse the software speudo antialiasing  u can find in AGG is just 
 a joke compared to  X16 antialiasing buffers that can be found on 
now in dayx accelarting video cards.

comparing AGG antialising and opengl antialiasing is like comparing 
the sun and the moon ...

the moon shines but it's only due to the refraction of the light 
comming from the sun that's prety much what the normalisation algorithms 
using in AGG does and they completly sux with tiny chars fonts... 
making them so blur or fuzzy as you like that you can't read them 
...

but in agg you don't have  a proper way to handle fonts who wants 
to have flat texels to represent is document or hundreds of  png 
files in memory ... and that where glut and other extensions try 
to give solutions but the réalisaton is in général ugly.

it embed an SVG engine ( even if i'm sure a rebol / agg one blast 
it ) support of freefonts  support of png (but only this image format 
where rebol works with jpg etc...)

well the fact is cpu are multi threaded multi cored and so are the 
graphic cards when you render a document  with AGG only that the 
freaking CPU that does the whole rendering work for God's sakes, 
it's like the computing on the 90's ... ok it's passed it's done 
it's deprecated and over now we have 650MHz GPU multi rendering pipelined 
and  multi threaded multi cored CPU over 2GHZ per core that's a lot 
of power and why would rebol be the only one not exploiting that 
... And in the near futur (5 years to come) the GPU and CPU will 
be merged in a single chip high performance.

let imagine you do a button you want to draw something on the background 
with AGG and then have the regular button borders and fonts to be 
applyed over  using AGG it's possible to have that effect  with the 
context phylosophy the VID button is a separated entity from the 
agg entity  you have the QT context the QT widgets display in it 
and the AGG widget is one of the few widgets you have but you can't 
mixe content ...

So, one could use AGG for somethings like a GUI and then use Cairo 
for display postscript

Any news how implementing command wrappers for AGG goes? Or on GUI 
status in gerenal? :-)

sure:


Robert - DB interface, messaging, state machine, cracking the whip
Cyphre - Resizing, low level AGG, rich text, host kit interface

Me - Dialogs, form validation, database interface, reactors, messaging, 
state machine help system
Bolek - Styles, resizing
Ladislav - Resizing, state machine


The above is basically what needs to be done for the first customer 
app.

Graham:


First prototype ready for review: DB interface, resizing, form validation

Coding: State machine, styles, messaging, reactors, dialogs, low 
level AGG, host kit interface
Pending: Help system

i'm not commenting what will be  done ofcourse i didn't see it.


But i already looked at the richtext engine carl proposed 2 years 
ago and that's far to be good.... 

In fact richtext engine is supposed to be dialect layer on top of 
draw. 

That dialect layer is adapted normally to handle text rendering the 
proper way which implies that the lower level text functionnalities 

in draw for text related effects is better done than previously. 
That's all i say ...


Building a layer richtext what ever it is if the AGG /draw dialect 
exploit poorly the text related effects that will be a pain and a 
very small benefit...

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

Not being an expect but IIRC R2 text rendering is not done using 
AGG. From this alone a lot of known problems might be coming.

In R3 text rendering will be through AGG. We will look into unicode 
as well right from the start.

but once again R2  AGG/draw text  wasn't desinged to handle this 
... we used fixed fonts because we had no other why to obtain the 
x and y size of each displayed glyph so in other word that a lack 
of a basic lower level function.

shadwolf for the 56743892th time, the font rendering is not properly 
utilized from AGG yet,

If AGG (or R2) was relying on the OS font rendering, the behavior 
shadwolf decribed could be caused by Cleartype. If Cleartype is turned 
on, but the REBOL renderer isn't rendering with compatible antialiasing, 
fonts would look bad.

This is not directly AGG's fault, since it might simply expecting 
different outlines for its rasterizer, or its not rasterizing the 
exact same way for which the outlines are expected to be used.

Just discovered: R3 doesn't use the same method for doing its font 
rendering as R2, it uses AGG instead. So it doesn't have the bug, 
and can be further improved.

what can be done to get more quality to the font display?

 I personally would make research about the technique McSeem(AGG author) 
 published in his well known font rendering related article and tried 
 to use the core idea of his demo application for making 'production 
 quality' version which can be then used in the HostKit code base.

Because AGG uses it ??

but that depends on the specifics of the engine.  afaik, AGG, in 
the way it is being used by view renders each element on the canvas, 
one by one.

again, I'd have to look at the AGG rasterizing pipeline to see how 
it functions, but the only procedural overhead is in how it inherits 
its origin at each gob.   


it might even be impossible from the get-go, based on how the actual 
rasterization is performed.  


in Flash this would be impossible.  but IIRC past discussions with 
Cyphre, we use a different rasterizing process, which would allow 
the whole idea.

IMO focus should be now on bug-fixing and closing open tickets. There 
is still some smaller things to do on the AGG side. And than get 
a V1.0 out of the door. Because I don't see any cause to not make 
an offical V1 release of R3 anymore. It's mostly ready for prime 
time.

one question for you Robert... is the A105 view/agg code stabilized 
wrt what I was reading for A104?

low-level use of AGG... not the R3GUI

A105 is the first one to integrate our AGG code line. So, bringing 
Carls work and our work much more in sync with less hassels for new 
releases.

I think with A105 the AGG externalization is done. There are some 
quirks left, to be fixed. But we can now do this on our own.

And yes, it's stable WRT AGG. I don't expect major architecture changes.

the only thing I have been wondering is how the gob type interfaces 
with the AGG... isn't gob! part of the core?

I'm not yet an expert, but I think that the GOB! get's converted 
to the AGG world. Hence, you can take the GOB! from Rebol and however 
you bring it on screen, just do it.

most stuff in src/agg/ is "just" the agg sources. the rebols-specific 
stuff in src/agg/ is in ~7 .cpp files, totaling just over 7k lines 
(agg_{compo,effects,graphics,truetype_text}, compositor, graphics, 
rich_text).

(but it may well be that i missed some stuff, haven't yet looked 
too deeply into the agg parts)

I meant the whole graphics sources including AGG.


there are many files... figuring out the whole calling order is going 
to be fun  :-)

Carl, a minor glitch in the A109 hostkit, which prevents it from 
compiling with AGG: in reb-lib.h the #ifdef __cplusplus definition 
of RXIEXT is borked.

Brian Posted a list in the R2 Releases group.


I also hope he included 2 fixes which I got Cyphre to address in 
view which crash or mock-up the quality in AGG.

Don't remember AGG related fixes

rebol is dead ...  it's dead since the rebol 3 project was started 
in 2004 just after AGG was integrated to vid and just after rebservice 
and rebcode were alpha done

thanks... its using liquid for all the rendering.  the canvas is 
 100% AGG even for the interactive stuff, there are no subfaces.

as long as it has AGG it would work. though its possible the plugin 
is old enough for a bit of the code to need some fixes.