AltME groups: search

Simulating AGG is not the main aim here. The first target is to replace 
rebcode in R3

ah, but you surely noticed what initiated this discussion? It was 
some test some guys did with the lib for AGG.

do the view parts work on debian, like AGG fonts?

why don't you simply use AGG to "stamp" each character in a bitmap? 
 using the draw command over and over (per character or per line)

placing bitmaps with draw is possible even in non-AGG versions of 
View

I would check the AGG documentation to confirm that though.

The above uses AGG scaling via the DRAW dialect. If you are converting 
many images, it should be faster than using LAYOUT all the time (and 
the code is shorter).

draw native has been added with AGG

I just miss being able to create proper thumbnails with draw AGG

I'm now reviewing one of my old View script and I need to turn of 
antialiasing to make it compatible with the AGG draw, what's the 
command please? I cannot find it.

(plus I'm not an AGG expert specifically)

I'm not using AGG in this instance.

newer engine will use only AGG which will compute more stuff on the 
fly... and thus would be more memory efficient... but at what cost 
in speed.  I hope that speed will not suffer, when compared to an 
app which does not use AGG.

AFAIK there exist some AGG fixes. Are they part of new View and when 
not, when they will be?

just ONE field with a linear fill in AGG, I have discovered, will 
bog down the whole display!

doesn't Cyphre already have an AGG SVG viewer

hum... I have the draw docs for AGG but it seems the gradient fills 
are (as usuall with rebol it seems) so documented, such that We have 
no real clue how the values change or what are the basis...

Maxim: I agree. There should be more info about the arguments. And 
yes, the need for 3 colors is just because the current gradient interpolation 
uses curve (this was some default AGG code we have used for DRAW 
but  now I think it would be better to rewrite it from scratch. The 
new code will use linear interpolator among other changes.)

the other big weekness is our inability to extract any kind of data 
from the AGG computed visuals.  cv info (for a text curve, for example... 
to match a graphic to its corner) , curvature data (length, coord 
+ angle at offset,  etc), box size, centroid (for quick searching 
of  computed visuals), all of this is vastly faster (we are talking 
like 10000 times or more here) when done in binary and available.

yes, the new gradients will be even more configurable. Regarding 
the access to the AGG  internal representation. I have talked about 
 this with Carl and we agreed in R3 it would be allowed to do functional 
programming of DRAW blocks. But all this needs more thinking...

only AGG text. Or you have to render text to bitmap (to image! face 
...) and then use the bitmap.

Is Font redering involved for Linux in the  testings?  Latest news 
on AGG fonts for linux was that it was not working, although I had 
it working once in a special /view version.. Looks now its not fixed 
yet.. No problem, but would be nice to have some kind of official 
statement in the docs for /view /sdk how that works/is fixed/not 
works.

Later on, guys improved situation a bit - including cool AGG vector 
library into View ... (www.antigrain.com ). This is really cool and 
puts Cairo into trashcan (which is what they should do in the very 
beginning, except the Mozilla politics)

View now switched its compositing fully to AGG, and it got something 
like 20x faster in some areas.

http://www.compkarori.com/vanilla/display/AGG

http://www.compkarori.com/vanilla/display/AGG

R3 does this elegantly already: It's based only on DRAW and all options 
for filtering from AGG are exposed. It fully supports high quality 
down and upscaling. :-)

I have a strange reaction in some AGG code...  calling show on the 
face is actually appending the new AGG drawing to previous such that 
the image is the result of all prior draws... but the draw stroke 
(verified) isn't growing!


anyone know what is causing this... AFAFIK I am not using the draw 
command, but setting the face/effect and calling to-image on the 
face.

I need the math, the main use isn't for AGG, but it will eventually 
have to be displayed anyways.

I was asking, cause I saw a demo once of someone rebuilding the AGG 
spline manually right over the AGG one.. so some code definitely 
exists.

seems that AGG hasn't been updated in 2 years!  should we fear it 
is being abandonned?

When last I heard, the guy got a job doing .NET stuff or some such 
and stopped developing AGG two years ago. Afaik he changed the license 
from BSD for 2.4 to GPL for 2.5, saying that "all future development" 
would be to the GPL version. However, the license change was the 
only difference between 2.4 and 2.5, and there was no future development. 
All afaik. So, abandoned, but BSD-licensed so who cares?

From my last talk with the author of AGG we can use even version 
2.5 without any problems. So far R3 AGG implementation is somehow 
blended between 2.3-2.4

Otherwise it is true the author(Maxim aka McSeem) is not active developing(at 
least publicly) AGG. But There is still small hard-core team  which 
keeps improving the code with little steps.

For example I'd personally would like to try implement completely 
new AA rasterizer which could make the rendering theoretically faster 
by 80-100% but this is long time run given my limited time.

Next step could be make HW accelerated frontend for AGG. But this 
is 'pandora box'  or 'can of worms' for me as I don't have energy 
to take care of all possible bugs in all possible GFX cards and setups 
at the moment :)

re Cairo: Cairo seems to be popular mainstream. But AGG is used in 
a lot commercial projects silently so it is hard to tell. The facts 
are:  
1. Cairo is slower than AGG.(when comparing SW rendering)

2. Cairo is a graphics library, AGG is a 'kit' to build graphics 
libraries.

I already told this here but I know AGG was used in this higher profile 
"indie" game: http://www.wikgame.com/

either you use AGG for aliased fonts, or you increase image size 
so its equal to the dpi you want to print.

I played around with it...
AGG looks great on screen but prints fuzzy like you said...
Increasing resolution looks sharp on printout...

I do not know if I should spend time playing with scaling or just 
biting the bullet and converting output to HTML or pdf ...I had planned 
on it anyway but as usual what I thought would be a quick one or 
two day project turns into a week to make it "right"...

But always an opportunity to learn new stuff!

MESSAGE TO ALL  :-)


I've finally found the way to drastically improve the overzealous 
mouse event handling within the lowest level of view directly without 
causing any noticeable side-effects in the normal face event handling.

its a small patch in view's wake-event function.


the only requirement is that you have at least one face (usually 
the window, if you can) which has a rate set to the response you 
need...  usually around 15 -20 is enough.


this makes face scrolling based on mouse mouse VERY smooth as there 
is no more lag ... which occurs because we can receive 2 to 3 times 
more events than view/AGG can refresh itself.

if you need this, please speak up, I'll gladly offer the recipe.

actually I think yours will be easy to convert to glass, since its 
already in AGG

Well, if you are able to make at least script that is able to crash 
(even randomly) I can test it here on external agg dll DRAW emulator 
to see if the porblem is in AGG code itself or if it is on the rebol 
dielaect side.

UPDATE on clipping crash..   


using CLIP NONE , seems to be the definite cause which makes AGG 
crash in my tests.

then BAM... a crash... so its back to square one... linear fills, 
when clipping, just crash AGG at some indefinite point in time.

Maxim, the first bug which crashes looks like DRAW dialect parser 
related as I tried it here with my debug library and it doesn't crash 
the agg engine itself. Unfortunately I can't test the original R2 
dialect part here.

The second bug with empty space in vectorial sctring is a side-effect 
of  one older known bug and I have already a fix for this one. I'll 
ask Carl if he can add that fix to the next R2 release.

If you do not have/need text or if you display text only thru agg 
instead of face/text, you can hide the superfluous caret in R2/View 
by setting the face's para to to an origin like -100x-100.

http://www.rebol.com/downloads/v277/viewpro-277-agg-fix1.exe

some AGG blocks crash ... are you using AGG?

no AGG

There is an AGG group, but there may be cause for a new "Draw dialect" 
group.

agg_truetype_text.cpp ??

rich text editing will probably not be handled at the AGG level.

I think I just found an interesting way to optimise AGG on R2  :-D 


I'm doing Animation tests with some complex vector & projection math 
(rotating/translating/projecting shapes using floating point math 
exclusively).


using AGG and a non-standard manual management of the window, I'm 
acheiving 0% CPU at 30fps FULL SCREEN (1440x900)

the system I am using now, is doing double buffering.  the AGG is 
rendered on the raster, and the call to show, tells view to update 
the window's bitmap so it reflects the changes to the raster.

image processing requires a lot of CPU juice.


 we have to render the AGG, use the bitmap in a face, apply an effect 
 on it, and then re-create a new bitmap out of it.  we aren't just 
 drawing/effecting over and over the same image memory area but creating 
 a new image at every refresh.


it would be nice if there was a complement to the 'draw function 
called 'effect.  maybe its in R3, or maybe it should be.

Thank for the example, Anton! Mind: Blown. I know Kung-f... I mean, 
how VID initialization works!


Here's my cleaned up (and working!) test program. It should be a 
little more generic than your example, since it will set values until 
it runs out of facets or pane items. Label styles are treated specially 
though, as you can see. Maybe now I can fix their set-face method...

    REBOL [Title: "Node Property Sheet" Author: oofoe] 
    ; Special thanks to Anton on altme/Rebol/View! 
    
    s: stylize [
    	title: vtext red 256
    	label: text 64
    	agg: panel with [
    		multi: make multi [
    			text: func [face blk][]
    			size: func [face blk][]
    			decimal: func [face blk][]
    		]
    		append init [
    			context [
    				p: pane  f: facets
    				while [all [not tail? p  not tail? f]] [
    					either 'label = p/1/style [
    						p/1/text: f/1
    					] [
    						set-face p/1 f/1
    					]
    					p: next p  f: next f
    				]
    			]
    		]
    	]
    	gpath: agg [

      across  label "Path:"  field 150 "Unspecified"  button "..." 30]
    	gint: agg [across  label "Integer:"  field 50 "0"]
    	gnumber: agg [across  label "Number:"  field 75 "0.0"]
    ]
    
    view layout [
    	styles s
    	
    	title "Project Settings"
    	gpath "main" %. 
    	w: gint "width" 1024
    	h: gint "height" 768
    	gnumber "fps" 23.97
    ]

This is so cool! I am excited!

Here's the agg style with get-face doing what I want (returning the 
field name with everything else in a list, suitable for dropping 
into a key/value list):

	agg: panel with [
		multi: make multi [
			text: func [face blk][]
			size: func [face blk][]
			decimal: func [face blk][]
		]
		append init [
			context [
				p: pane  f: facets
				while [all [not tail? p  not tail? f]] [
					either 'label = p/1/style [
						p/1/text: f/1
					] [
						set-face p/1 f/1
					]
					p: next p  f: next f
				]
			]
		]
		access/get-face*: func [face /local p label x] [
			p: face/pane
			label: to-word p/1/text  

			p: next p
			x: copy []
			while [not tail? p] [append x get-face p/1  p: next p]

			return reduce [label x]
		]
	]

one thing which is nice in the current system is that I'm not using 
pairs, but blocks of two float values, so a part from the actual 
AGG coordinates, everything is floating point and quite precise.

right now, I'm still flushing out the raw maths, but somehow, AGG 
always seems to squash any speed gains I get out of better interpreter 
speed.

Using R3 with stuff compiled and sidestepping draw in order to use 
AGG directly would probably allow several hundred frames per second 
for this simple test.

it might be possible to use a callback and allocate our own OS timer 
via library calls, but I think it not worth the hassle.  going past 
32 fps didn't produce noticeably smoother animation, and it allows 
much more time for (slow) math and AGG rendering in REBOL.

its already an issue that AGG or the GC seems to be generating a 
steady memory leak at each refresh, which I will have to investigate 
further.

from a normal REBOLer's perspective I don't see any different way. 
 Don't get me wrong, draw and gobs are usefull and cool.
plus, in R3 there is some optimisations by using GOBs afaik.


but for fast Gaming, I'd completely forget about gobs, and draw and 
just allow access to the AGG  C functions as commands in REBOL.
 rasterized and displayed in a window's bitmap directly.

Max - so far, all AGG functions are mapped just like commands, nothing 
more. Cyphre is working on a dialect right now, but it is not in-there. 
Each dialect keyword then maps to such a function - or how do you 
think the REBOL to AGG mapping is done?

for some reason, the text command was exported, and when I tried 
to use it, it just crashed R3.


the whole system requires you to tell it where to draw stuff. all 
the C code  expects either a gob! or a low level AGG graphics object.

the issue is mostly that they need to know where to draw themselves. 
 which is not something I've seen refered to anywhere outside of 
the higher level draw commands and AGG calls.

my use cases tend to be on the fringes  ;-)


but I don't want to impede their plan right now.  i can actually 
do (some/all?) of this work myself, since it would effectively be 
a completely separate rendering process than /view, I woudn't be 
competing with their efforts, it could just be an additional extension 
which uses the same AGG code, but with a different REBOL interface

most of it is math, AGG is just reflecting the vector maths I am 
doing.  its also responsible for about 90% of the CPU use :-(


but for now its not an issue since the game kit doesn't actually 
use these shapes for the user graphics, only for collision detection.

the user graphics are statically bound pre-compiled AGG blocks and 
render much faster, since I use AGG matrix ops directly for all of 
the rendering.

for the particles, either pregenerate (and simply offset) small faces 
with an transparent image or build an AGG block at each refresh.

reposted from 3rd March, AGG group

another thing I've seen which causes immediate close is the use of 
"some" AGG constructs which crash the interpreter silently.


chief among them is to use line-patterns which more than 2 colors. 
 it doesn't always crash, but *it will* suddenly, without warning, 
IIRC.

yes, that is true ... but someone here was working on fmod ... and 
Carl told me that if fmod goods as good as AGG is for graphics, he 
may consider it .....

- Pekr : Carl hasprepared his presentation the night before he given 
it (so he was not in great form this particular day ;-)


- About Internet connection : the scholl connection where we were 
is provided by an Italian telephon companie that ensure the security. 
Mario have tried more than a week before to have some opening on 
it. Lot of faxes, telephon calls and time lost. We were all disapointed 
of that, in or outside the Devcon.


- Rebcode : it will be part of Rebol soon. You can even try it if 
you want (windows builds folder, the zip file). But it still in design 
stage. The form, the capabilities and implementation are sugest to 
changes. Carl has insisted on the fact that rebcode will be a bit 
tricky to use. Kind of assembler code. Not for newbies.


- Rich text : Cyphre show us its work. Actually it's a .dll, like 
he did with AGG in the begining. It's not just a renderer : it's 
editable rich text. Dialect base like Carl's blog proposed. Nothing 
more to say, it's just a prototype, a proof of concept, like AGG 
was at its time. It use AGG as engine, so font can be aliased or 
not.

I wonder about further AGG integration - you know, AGG added even 
compositing engine lately, so maybe Rebol's native one could be exchanged 
:-) Also there are now effects provided in 'effect level and AGG 
level, that is inconsistent .... what is more - with rebcode coming, 
we can do most effect ourselves and hopefully be fast enough?

I have asked Carl about the problem of effect and draw different 
engine. He answered that the effect engine will be replace by AGG 
at terms. No schedule.

Q: Yeksoon asks "Reichart, there is a whole bunch of pple under Rebol 
SIG in QTask, .... are a lot of them working on QTask etc?"

A: Yes.



These are answers from Carl, Gab, Richard, etc. from the last day 
of the conference.  I sat them all down, with many others from the 
conference, and we reviewed and tried to lock down answers.



1) Will rich text and rebcode became part of all rebol distributions 
from now on?


A: Carl said "Once Rich Text and Recode are added (which was agreed 
on to be by Nov 14) ….yes."


2) we heard answer for async kernel in regards to LNS - some time 
ago Carl mentioned proper tasking or even timers could be added - 
is that anyhow realistic?
A: 


Carl said "Tasking is special, and is pushed off to Rebol version 
3."

No date has been set, but it will not be now


Carl said "Timers could be done now, and this could be done in a 
few months."


Carl wants more feedback that people "need" them.  So give him feedback. 
 This also goes to say we need a common place where we all (in the 
Rebol community) can create a complete list of what is wanted, and 
then "vote up" the things we want done first.  So RAMBO for now, 
perhaps Qtask soon, since it will have Voting.


3) I realized VitalNeeds removed all Rebol related info from their 
website - is the partnership lost?

A: Carl said "No, but they are talking…"

4) what will be the next focus of RT?

A: Carl said "Altissimo"


5) there was some talk about "rebuilding the team" - will RT employ/contract 
more developers?


A: Carl said "Yes, and we are doing , send in your Resume and show 
us your cool app you wrote that is as good as Canvas!"


6) some time ago Carl talked about opening some of rebol code - parts 
of View, console etc - will that happen? 


A: Carl said "Yes, this is happening and is happening in pieces. 
 The console is a good example.  Nothing would make us happier than 
having people make it better, and not have Rebol be the bottleneck."



6.2) Part of that plan was "Rebol as a library" IIRC - is that concept 
still valid? 


A: Carl said" It exists today!  Look in Windows directory for the 
DLL.  You can call it. More is being worked on. Talk to Jaime."


6. 3) What happened to /Platform vision? I was not present last year 
at Devcon, but my understanding was, that /Platform is about modularisation, 
language plug-ins were planned too ...


A: Carl said "Platform is being sold to Safeworlds…"  I will comment 
on this later.


7) not to mention BCD, rebin, RIF, of which only RIF was mentioned.


A: Carl said "We found another aprouch to BCD, so it was good we 
waited, Ladislav will be making this happen."



8) RAMBO is cool - but what about shared roadmap? I was contacted 
privately by one former Rebol developer, who felt Rebol plays on 
elite and that not knowing what is the plan for what product is really 
badly frustrating. Will RT create more SIGs, to fasten developments 
in certain areas? I talk about kernel areas, which general rebol 
user can not affect and waiting for enhancements can take years. 
Some ppl are already crying for better sound (if we want to use rebol 
for video-over-web for eg.)


A: Carl said using Sound as example "Sound: a good example of code 
Rebol plans to make open.  AGG for sound, would be perfect for Rebol. 
 I am more than happy to publish this info."

 


9) We heard about spreading rebol x-times. What is RT's vision of 
how to achieve this? Such claims should be supported by some more 
concrete plan? Is still outer world (development companies) interested 
in Rebol, so maybe more of VitalNeeds partnerships could come?


A: Carl said "This is complicated question…and answer.  My belief 
of the world is that application have to be simple to use, and to 
make.  That is what changes the future of computing.  So I see a 
world with thousands of developers, making all sorts of applications, 
with that it will grow faster than anything else that has been done."
 
10) What is Carl's preferred drink? :-)


A: Carl says "Non Alcoholic.  POG.   Otherwise…Vodka Martini, with 
Green Olive…very dry…(stuffed)"

From Yeksoon:


1. RT official statement on current products line like View, IOS 
etc?

Is it going to be replace by other range of products...support etc? 
How does moving 'beyond' View, IOS affect the current product offerings 
and hence the way alliance partners operates.


A: Carl says "Yes, we are going to move beyond, the new features 
WILL make this more usable and faster, and more open than in the 
past."



1.2: For partners like myself, who are on the alliance program, we 
would appreciate if RT works closer with us on their commercial offerings, 
roadmaps etc. We need such info to make decisions ...


A: Carl says "what we will be doing for Alliance, is help them move 
foreword on the new tech that is introduced, and with the minimum 
amount of effort."


2. How does the above decisions from RT leads to X% growth next year? 
Are there any change in the way business is done?


A: Carl says "Yes, it is going to change a lot, and this will happen 
over the next year.  This should bring you much better range of features, 
and enhanced as necessary by your teams."

next - I don't understand AGG for sound? Is that just analogy simple 
that we should be looking for kind of AGG library for sound? What 
does Carl mean by  "I am more than happy to publish this info"? So, 
maybe we should look more closely into fmod.org finally (or some 
other library) :-)

@Pekr: "next - I don't understand AGG for sound? Is that just analogy 
simple that we should be looking for kind of AGG library for sound? 
What does Carl mean by  "I am more than happy to publish this info"? 
So, maybe we should look more closely into fmod.org finally (or some 
other library) :-)" 

As you thought Carl meant basically that someone has to find a sound 
eqivalent to AGG and (probably do the work Cyphre has done (my understanding)) 
it could be integrated into Rebol.

Graham, I never said I don't need sleep, I simply need 4 hours of 
sleep.


Brett, no mention of Cell phone work, although we are working with 
Palm right now on making Qtask work with Palm as a Client.  It will 
be written 100% in Rebol.


Tom, Actually it was very serious.  He is going in for neck surgery 
Thursday.  They are talking to him about the fact that he could be 
a QP.  He is the smartest person I know in the world, this is very 
hard him and myself.  He is a world traveling (sold his company to 
Adobe years ago and is/was working on his own very important project). 
 I'm forcing him to stay with us, and I mean that in many ways.


Pekr, Safeworlds will make a formal announcement.  We are still working 
on stuff.  Altissimo is AltME 2.0, and we are working more closely 
with Rebol.  Things are looking good.


VID, someone else will need to answer, I think I missed the clear 
answer also.


AGG sound, yes, I Carl was expressing that it needs to be a standard.


As for all the new questions, I suggest using either the Checklist 
here in AltME and create a single question per line item, or Qtask. 
 This way we can confirm the important questions get answered.


Michael, I agree, many concrete things were stated.  Rebol has been 
hiring people.  It is using contractors as well.  Several big projects 
will be completed by the middle of November, more are coming, etc.

FOG - new gfx library based upon AGG ... from the author of ASMJit/BlitJIT 
- http://twopixels.blogspot.com/2009/06/fog-graphics-library.html

I think that we have some tests to try with AGG, once we get back 
to GUI :-)

it seems a cousin to the glass project, of which glob is already 
very effective, and is a node-based lazy engine for rebol, using 
AGG exclusively.

I should also note the basic/default gfx engine (agg) we use can 
run on any king of brick that support framebuffer so this part is 
the last to be worried about.

And even if anyone can switch to other gfx engine this is already 
possible at the hostkit level.

I must say that the current hostkit gfx abstraction layer is not 
100% polished yet (but this will happen soon) in terms of 'programmers 
comfort' but it is pretty usable in the A110.

REBOL/Command for Linux includes AGG (without View/VID), so no dependencies 
on any X11 libs, can be a workaround while waiting for R3.

I realy thought AGG was already inside rebol/view for linux ?

so for elixir, I am thinking of building an OpenGL interface AND 
an AGG view based one using the same software. in fact, we could 
even have two simultaneous symmetric windows running and 0% code 
to add in the software :-)

(one in AGG and one in OpenGL, to compare them)

you know guys, in a sense I already have a 100% working dataflow 
view.  and it took me 2 hours to build the whole gadget architecture 
on it and about 30 minutes to write my first integer field... and 
its all AGG.  and its 100% bug free.

I'm using it in elixir, but AGG is a limiting factor right now... 
once it gets to pretty it starts slowing down.

you mean not recompute the AGG shapes at every show? i think Cyphre 
did it this way.

altho i do have another inhouse editor ive made with agg/draw

one thing that I would love for R3 is the ability to directly access 
the image byte data of a rendered window - a read only ability would 
be fine - or even editing with a lock/unlock mechanism.  The main 
reason for this is the allow direct pixel analysis for non-standard 
interfaces - eg AGG/Draw based interfaces where colour can be used 
to determine function of an irregular shaped button.  The basic premis 
is that you draw your UI composite then rather than having to do 
cumbersome bounds checking you can simply test the pixel colour under 
the mouse and call an activation function based on that colour - 
eg 0.0.254 = a save function.

they can already take AGG and link to it.

Gabriele - they linked already to it! They have bounties for projects 
and they don't hesitate to call it Rebol/View clone! It took 3rd 
place. Then I saw, how author was disappointed, linking to AGG, how 
slow it was :-)

well... view is mainly compositor built on AGG. i don't think it's 
interesting for those guys.

currently we have rebhost.exe (which contains agg compositor) linking 
to rebol.dll

there was some simple script measuring FPS (refresh rate), it would 
be curious to see how AGG compositing helped us.

AFAIK GLUT is simple wrapper which has been used mainly just to show 
some basic OpenGL demos. I'm not sure if this is a good  for usage 
in some 'real' crossplatform apps.

Regarding the OpenGL version of Rebol: this version is not yet worked 
on but I plan to work on it once the AGG based version is complete 
(as it this will give us much better big picture where the OpenGL 
advantages could be really useful in the visual system).

AFAIK the plug-in interface is not yet finalized so it is too early 
to discuss ho this will be exactly exposed.


But there are more things to consider than the blitting. If you do 
SW redered graphics you need to render into the  backbuffer in the 
main memory then you transfer block(s) sing a blit to the gfx card. 
If you do HW accelerated graphics you need to transfer all bitmaps 
into the gfx card memory first..also you are limited by the OpenGL 
2D functionality (which is not so flexible and pixel perfect as for 
example AGG implemntation). Also setting pixels directly in gfx card 
memory is possible but this is surprisingly the slowest way to dorendering! 
Why? Because fur current PC HW bus architecture is such transfer 
very expensive operation comparing to moving one big block of data.

So as you can see all this (and lot of other issues) needs to be 
considered not to mention that the solution should be as much as 
compatible on most of platforms.

Once the beta is released it will give us good picture how to make 
the gfx system even more optimized and extensible.

hmm, but that is something different, no? It is not subpixel accuracy 
AGG allows?

Imagine - if Cyphre worked on View kernel alone, he imo concentrated 
upon rich-text, proper AGG integration, etc.