AltME groups: search

sparse matrix

I also find that all types should be described within a convertion 
matrix.

Maybe you could make a block with the titles and the objects together, 
and then just use a path to get to the object? Something like:


>> movies: reduce ["Star Wars" make object! [status: 'good!] "Matrix" 
make object! [status: 'cool]]
>> movies/("Star Wars")/status
== good!
>> movies/("Matrix")/status
== cool

Adding more and more natives schemes (like matrix operations on series) 
is the way to get Rebol more and more powerful

Matrix - There is no spoon ...
REBOL - There is no R2 ....

... forget R2 :-)

I have a question about the matrix functions in Draw.  Is it true 
they can only be applied to an existing draw sequence?  that is ,I 
am creating novel points to insert into a polyline that is yet to 
be drawn, it seems I cant  use the matrix functions to generate these 
points.

Does anyone here know about matrix math and can advise me on how 
to derive the same transform as is made by the draw dialect's IMAGE 
command with four arbitrary corner points ?

Anton, I know about matrix math and have a book here with the standard 
4x4 matrix operations for transformation like rotation, scale, etc. 
in 3D, if you need those. But are you sure, AGG use matrix math to 
do the 4-corner IMAGE trick? I would guess, it's some (2D) texture 
algorithm.

Good question, but I don't think so. And should it be position related 
to last command, or should transformations be taken into consideration? 
Like:

.... effect [ draw [translate 234x123 matrix [1 0 0 0 -1 0] line 
20x-20 40x40]]
What is position?

When drawing, I would like to translate the X to 0 and Y to ( Y + 
28 ). What the Matrix should be? Thanks.

I mean using the Matrix command in Draw, like MATRIX [a b c d e f]. 
The Matrix command would premultiply the current transformation matrix 
with the given block. What should I assign this block to translate 
the X to 0 and Y to ( Y + 28 )?

Forget about my previous question, I am not going to use matrix in 
this case.


For rendering cahracter images, I thought that relative-positioning 
could be a good idea. After drawing a character image, then shift 
(translate) to the next position, and the next character would be 
in the right position. So I made my draw block some thing like [ 
image char1-img translate rp1 image char2-img translate rp2 ]


It worked, but the rendering performance was slow, way too slow. 
So I go back to my good old absolute positioning. [ image char1-img 
ap1 image char2-img ap2 ]. No more "translate", no more matrix.

stylize/master [

 matrix-area: area with [colors: [0.0.0  0.0.0] font/color: 150.255.150]
] this makes all font/colors 150.255.150

matrix-area: area with [colors: [0.0.0  0.0.0] font: make font [color: 
150.255.150]]

or
stylize/master [

 matrix-area: area with [colors: [0.0.0 0.0.0]] font [color: 150.255.150]
]

the above code is in a block called matrix_panel
then attached to cal_panel with :

cal_panel/pane: layout/tight matrix_panel

just after : cal_panel/pane: layout/tight matrix_panel

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.

Reichart: There was a quote Carl made (he was quoting someone else) 
comparing Rebol to the Matrix as being something "you either get 
or you don't".  On a parallel note, I'd cite the first panel in this 
Xkcd: http://xkcd.com/566/

I thought matrix was only a way to merge scale rotate and translate 
values...

Cyphre have you an idea when the bug with matrix will be solved ?

Didec work like a layer difinition and manager

Using push the matrix or other trnasformation information are apply 
only on the push  block content. outside the push block the matrix 
informations are not affected

I would like to know when the problem with Agg Matrix will be solved 
and when Carl plans to integrate in REBOL/AGG a radiant function 
that can better feet with SVG datas  ? I started 3 month ago an SVG 
engine and since then I'm stuck because of those 2 problems... SVG 
without transformation matrix and without gradients it's like nothing 
.... ( see greoup SVG renderer for more informations and test code)

I tryed svg-demo-shad06.r under linux with wine rebol/view 1.3.1d 
and with the rebol/view 1.3beta version and the SVG renderer script 
present the same matrix tra	nsformation problem but the good news 
is that the rebol/view 1.3 for windows  and the rebol/view 1.3 for 
linuw are working both on linux using svg-demo-shad06.r script

Svg  works need a dubeged matrix  -> scaling problem  and  gradients 
that feet ratio  information and   not  fixed area  ^^ those things 
can be script coded but this will complicate the SCV rendering engine 
and makes it slower for nothing ...

Shadwolf: the matrix problem you had should be fixed in DRAW 1.3.2. 
The gradient ratio parameters will be added probably in the next 
release.

Ok, so here it is:

-fixed image keying bug (swapped color components in keying tuple!)
-line width is now now changing according to scale

-fixed rendering of transformed images(now uses aplha premultiplied 
data)

-fixed LINE-PATTERN bug (multiple line patterns in DRAW block should 
work properly now)

-fixed MATRIX bug(wrong matrix calcualtion was corrected in this 
case)

-fixed SKEW command inconsistency (now it takes degrees as arguments 
instead of radians)

-fixed FILL-PEN bug when filling images (now it doesn't render images 
upside down)

-fixed ANTI-ALIAS cmd(now it is possible to switch this mode within 
one DRAW block)

-removed POP command (was obsolete, PUSH with block! arg is used 
instead)
-fixed fill/outline pixel aligning problem
-fixed visual bug when rendering circle with line-width > 1
-fixed text character encoding problem
-improved gradients: added REFLECT and REPEAT modes, example:
view layout [
	origin 0
	box 400x460 effect [
		draw [
			pen none
			fill-pen linear 10x10 0 190 0 1 1 black red green blue black
			box 10x10 390x90

   fill-pen linear 10x160 0 190 0 1 1 black red green blue black repeat
			box 10x100 390x180

   fill-pen linear 10x310 0 190 0 1 1 black red green blue black reflect
			box 10x190 390x270
			fill-pen radial 80x350 0 20 0 1 1 black red green blue black
			circle 80x350 70

   fill-pen radial 190x350 0 20 0 1 1 black red green blue black repeat
			circle 190x350 70

   fill-pen radial 320x350 0 20 0 1 1 black red green blue black reflect
			circle 320x350 70
		]
	]
]

Cyphre as far as i test matrix problems have been solved in REBOL/view 
1.3.2 

this image was done with 1.3.1 http://shadwolf.free.fr/SVG-rend-compare.jpg

This one is done wth 1.3.2  http://shadwolf.free.fr/svg-renderer-v07.jpg


now i have to found the good way to exploit and work  with some SVG 
datas. the gnome keayboard image is good but i still get some scaling 
problem with the orange part of the blender logo image  (the disposition 
is good but the sacle is not good )
see:
http://shadwolf.free.fr/svg-renderer-v07-2.jpg

so as you can see the compositing of the relative orange part is 
good it's relative position seems to be good too but now that's the 
scale wich is not good it"s like if it was disabled .... 


My SVG rendering engine is designed to work perfectly with ink scape 
SVG format.

oki i send  you by mail right now   the  lastest svg engine script. 
I identified the  matrix compositing  line code   search  "Cyphre 
!!!"  in the  script. I added the svg file with the  blender logo 
(witch  use tranform matrix information)

cyphres did you looked at my  SVG rendere and the matrix problem 
in it ?

Anton is right. DRAW works on lower level than FACE so there is only 
one tranformation matrix per DRAW block (ie. it is applied on all 
rendered primitives). OTOH you have relatively wide range of commands 
how to control the transformation matrix or even use the mtrick stack 
to push/pop different trnasformation states to apply  nested transfromations.

In the new DRAW/AGG dialect, it seems that the 'reset-matrix command 
just don't work with 'matrix or 'translate. I've tried the examples 
from TRANSLATE command found in the online DRAW documentation, the 
2nd and 3rd examples are supposed to reset the translation, it just 
don't work (unless I've missed something obvious). Tested with View 
1.3.2.3.1 and View 2.7.5.3.1. Examples URL: http://www.rebol.com/docs/draw-ref.html#section-3.33

Whatever method I use in my DRAW code, I keep having the cumulative 
effect on TRANSLATE (and also on MATRIX).

(ie the third box 'offset' starts at 100x100 so after reset-matrix 
it is at 150x150)

To clarify it have a look at result this example:

view layout [
	box 600x400 effect [
		draw [ 
			fill-pen blue box 50x50 150x150
			translate 50x50 fill-pen red box 50x50 150x150
			reset-matrix
			translate 70x70 fill-pen yellow box 0x0 100x100
		]
		draw [
			translate 200x0 
			fill-pen blue box 50x50 150x150
			translate 50x50 fill-pen red box 50x50 150x150
			translate 70x70 fill-pen yellow box 0x0 100x100
		]
	]
]

I'm hoping the transform matrices will work recursively, properly, 
so we can build a hierarchical object, eg. a body with connected 
arms free to rotate around the shoulder, forearm free to rotate at 
the elbow, and hand free to rotate at the wrist. For this to be drawn 
correctly, clipping regions etc. must work locally to the current 
matrix.

another question: in the current alpha, the matrix command seems 
not working like anounced in the wiki, is it normal ?

Steeve, if you can make some examples with the matrix command, we 
can make an entry in the bug tracker.

well My svg engine is working and got trouble only with matrix calulations 
due to an odd bug in the adapted version. Next i don't like the way 
my SVG works  I wish to be able to do it  in plain parse way (My 
method in not really elegant but it works fine  in most cases SVG 
is an XML file so the XML data is converted to REBOL  objects using 
parse and then i process those objects to convert into draw/Agg instructions). 
That was the fastest way i found at that time since what was important 
to me was the result not the beauty of the processing way.

I have discussed this with Henrik already but reposting here so anyone 
knows.
This is actually caused by one 'optimization' feature. 

Currently if you are not changing the transformation matrix the engine 
uses faster routine for image rendering bypassing the image filter/interpolation 
code.

The decision is based only on simple fast test if the matrix have 
changed.

So to make it 'smarter' we need to improve this optimization decision 
condition so it checks if there was only scale/rotation applied to 
the matrix and ignore the translation changes.

Then it will use the faster rendering also for simple translations 
without scale/rotation.

Plus, If the the interpolation process is based on matrix calculus 
only. There will be ne no gain.

I mean a simple translation can be seen as a matrix as well and it's 
probably how it"s managed.

If I understood correctly what he meant. There is an unique transformation 
process (unsing matrix calculus). The same matrix mix all the effects 
(translation, rotation, scaling)

there will be no gain when scaling and rotation are ALSO applied 
to the transformation.


but if there is ONLY translation, then there is no need for any interpolation 
or matrix calculus... just a simple blit as if you do:
draw [ image my-image 30x30]

Steeve: by looking at the matrix it is very easy to see that there's 
only translation.

Yes, Gabriele and Maxim got what I meant to say. Steeve, not sure 
what you mean.

Basically It is possible to add any code that analizes current matrix 
state at this point but I guess simple check if only translation 
was applied will be easiest, fastest and suit majority of cases.

Re "How to solve systems of linear equations in REBOL?" - generally, 
you can use the matrix operations posted to my site:

http://www.fm.tul.cz/~ladislav/rebol/matrix.r

pretty smooth - maybe I have to try it one day ... what I did was 
put a lot of text in Carls first test of the transformation matrix 
example, where he wanted to know if the behavior is correct - and 
if you have a lot of text and zoom into it, it gets slow - but there 
are people here who know better (and might prove me wrong) - for 
me it would be too nice if somebody proves me that the same stuff 
as in the link is in sufficient speed possible with Rebol, even if 
there has to be some clever arrangement of the objects to be shown 
- I mean that objects not visible don't get rendered

3) How close to a working SVG renderer are we? ;) I'd really like 
to incorporate scaleable Icons, especially since the Tango links 
I posted previously have all their icons in dual PNG / SVG formats


So as SVG  master (yet again drunk ???? hum yes but that's last year 
night and first new year one so it's allowed to be hum lets say a 
little joyfull ) The answer is  easy SVG renderer is yet fully working 
as the matrix problem was internal to the VM and not to my code I 
simply need to disable the commented matrix line of code in my rendering 
engine and make the testing with the wonderfull, marvelous, extraordinary, 
free of bug version of REBOL/View 1.3.2 (?) The last issue is the 
gradient formating ...  and then we get a full 1 to 1  WYSIWYG svg 
rendering engine. This needs some testing too and some optimisation. 
You know me I seek first of all the full fonctionnality then i see 
if optimisations can be done to enhance the project (and in lucky 
rare cases my brain pop out a yet optimised solution but inspired 
by previous works like for listview widget wich was designed in an 
optimised way beacause of many inspiration projets were yet available 
 for this topic... )


For caret  system yes .... hum this remark was undirectly adressed 
to Carl we yet talked a lot on this topic on View Group last year 
 but it's good some time to recall previous unsolved discution and 
try to see if we can help Carl to change the design at least apporting 
to him some fresh ideas or only poping out why we found it really 
annoying based on our experiences and intents (like my mini ritch 
text editing widget using AGG to render the typed text  for example 
( see AGG group for code it's not long it's not fully working and 
it perfectly show as hard the handle of the caret position is!) .

For ppl interrested in  SVG rendering engine. My  tonight work  and 
 test on the engine   is resumed in the AGG topic. To resume before 
matrix bug as causing bad scale and bad position.  Now we have good 
position but still bad scale  i post screen cap samples and we can 
see that the evolution is good  betwin View 1.3.1 and 1.3.2

Currently my problem is with the linear gradients when a matrix operation 
is applied on them.


The linear gradient use a vector v = (x1, y1) - (x2, y2) to indicate 
his direction and length.


grad-pen is defined like this:  [grad-pen linear normal xy 0 len 
angle [... stop colors]]

And i calculate his values with:

- xy = (x1,y1)
- len =  length of the vector v 
- the angle of the vector v


When a matrix is associated with the gradient, i multiply the coordinates 
of the vector v by the matrix before calculating the other values.
It's working well when the gradient is vertical or horizontal.

But when the gradient is inclined , the matrix multiplication give 
a wrong vector and i don't know why.

Well, assuming you got x1,y1,x2,y2 from the Lineargradient

I calculate the angle like that:
arctangent (y2 - y1) / (x2 - x1)

As i said previously, the angle is correct when there is no matrix 
transformation on the gradient.
I compare the rendering with what i see in Inskape.

when matrix transformations are applied, some are wrong, but hey 
! Quite a good result already !

This matrix must not be applied on the gradient's vector as-is, but 
on something else.
And i found what, at least...


The documentation of SVG is lacking of a good explanation about this 
curious matrix transformation.
All we can read is that curious sentence:


When the object's bounding box is not square, 
the stripes that are 
conceptually perpendicular to the gradient vector within object bounding 
box space 
will render non-perpendicular relative to the gradient 
vector in user space 
due to application of the non-uniform scaling 
transformation 
from bounding box space to user space

What does that mean ?????


It means that the SVG gradient must be rendered without using the 
matrix transformation.

And THEN the transformation matrix must be applied on the resulting 
strips.

You see the problem ?

The matrix must not be apllied on the gradient's vector, but on the 
resulting strips produced by the use 
of the initial gradient's vector.


What foolish morons have designed such a complicated way of constructing 
gradients.

Can't they just give a matrix that can be applied on gradient's vector 
as-is, no they can't, it's to simple.
Morons, I said !!!


Because of that i had to make more transformations to obtain the 
REAL vector.
step by step I do something like that:


1/ Take the initial gradient vector V and apply the matrix on it, 
it gives a vector V1

2/ RE-take the initial vector V, rotate it of 90 degrees, apply the 
matrix on it, and rotate back the resulting vector
. It gives the vector V2

3/ Project the vector V1 on the line V2 (orthogonal projection). 
It gives a third vector V3.
4/ That's all, the REAL vector to use for the gradient is V3.


It take me a while to figure that, by analysing the Inkscape rendering. 
Morons i said !!!

I show you that part of my code...

		switch type [
			linear [
				unless x2 [x2: x1]
				unless y2 [y2: y1]

				if matrix [

     ; ** apply the matrix on the vector rotated of 90°, then rotate it 
     back,  give the vector V1
					set [y1' x1'] mulm y1 negate x1 matrix
					set [y2' x2'] mulm y2 negate x2 matrix
					x1': negate x1'
					x2': negate x2'

     ;** apply the matrix on the initial vector, give the vector V2
					set [x1 y1] mulm x1 y1 matrix
					set [x2 y2] mulm x2 y2 matrix
					;** project the vector V2 on the line V1
					set [x1 y1] project x1' y1' x2' y2' x1 y1
					set [x2 y2] project x1' y1' x2' y2' x2 y2
				]
				angle: atan2 x2 - x1 y2 - y1 
				if units = "objectBoundingBox" [
					x1: box/1/x * x1
					y1: box/1/y * y1
					x2: box/2/x * x2
					y2: box/2/y * y2
				]
				out as-pair x1 y1	;** offset
				out 0				;** start rng
				out square-root add x2 - x1 ** 2 y2 - y1  ** 2	;** stop rng
				out angle			;** angle
			]
...

Ok, i finished with Radial gradients (less the impossible feature: 
2 different centers)


SVG use a matrix transformation to convert a circular radial gradient 
into an ellipsoid.

And you know what ? 

We can do the same thing with grad-pen which provides 2 scalling 
factors (grad-scale-x and grad-scale-y)

So in that case it's easier than for linear-gradient.
1/ take the focal point of the Radial gradient (fx, fy)

2/ Create 2 vectors starting from this point: 1 vertical and 1 horizontal, 
using the radius as their length.
3/ apply the matrix transformation on them.

5/ get  the component X of the transformed horizontal vector, and 
the component Y of the transformed vetical vector
6/ grad-scale-x:  x / r
7/ grad-scale-y: y / r

That's all folks

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 ...

As far i am, i made some useful tiny mezz, perhaps some could be 
in R3.

reuse: funco [b [block!]][head reduce/into b clear []]

** REUSE, reduce a block, but re-use always the same block 

** Actually, 3 time slower than a reduce block, but save memory and 
GC recycles if used massivly.
** I use it to pass small blocks of coordinates.

mulm: func [

 {multiply a matrix [a b c d e f] by coordinates x y, return coordinates 
 [x' y']}
	x y m [block!]
][
	reuse [x * m/1 + (y * m/3) + m/5 x * m/2 + (y * m/4) + m/6]
]

atan2: func [

 {Angle of the vector (0,0)-(x,y) with arctangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

Project: func [

 {orthogonal projection of a point P on a line AB, return coordinates 
 [x y]}
	ax ay bx by px py
	/local sx sy ux uy ratio
][
	sx: bx - ax
	sy: by - ay
	ux: px - ax
	uy: py - ay
	ratio:  sx * ux + (sy * uy) / (sx * sx + (sy * sy))
	reuse [ratio * sx + ax  ratio * sy + ay]
]


vector-length: func [x1 y1 x2 y2][square-root add x2 - x1 ** 2 y2 
- y1  ** 2]

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

The lock in is in mentality. All the cloud crap, not having the date 
at my location everything on server. Welcome matrix :-)

A datamatrix can hold 2K per bar code .. so we would have to create 
a matrix of datamatrices to store the data we need on a page

push in the draw dialect? that saves the matrix on the stack, so 
i'm not sure i understand you 100% here.

the thing that OPenGL  is not rendering on screen anything It mainly 
offers matrix handling routines and GLUT does the rendering on screen 
...

I don't plan to support Draw rotation, translation or matrix operations 
in the first release, but someone can add it quite easily.

for one, arrays of tightly-packed values we can use in external calls 
directly... like matrix transformations.

i don't ask for matrix operations currently (like adding or multiplying 
2 vectors).

I just wonder why simple tricks like adding or multiplyings all the 
cells with a scalar is not allowed

You'll have to wait for multiple-dimension vectors before we do matrix 
operations :)

Steve - isn't convolution (where you set matrix too) enough for image 
manipulation type you mention?

Having the ability to apply some math and matrix operations over 
vectors would be nice. Having the ability to use such functionality 
to modify some binary (e.g. image) would be cool too.

are there any matrix operations for vectors?

priorities are a matrix... everyone does the error of viewing them 
as a list.

I think so.
The only remaining problem will be the transform attribute.

They can apply a matrix to transform the gradient. But we don't have 
that, as-is in Draw.

We can apply rotate, scalling, and translation (i guess) on gradients, 
but separatly, not as a matrix.

Do you mean, taking the matrix and extraction the different components 
(rotation, translation, scaling) ?
I don't know if it's possible, i'm not good enough with maths ;-)

read/as ftp://ftp.rebol.com/matrix.avi[ file: %movies/matrix.avi 
]

and to resume


read/ask/seek ftp://ftp.rebol.com/matrix.avi[ file: %movies/matrix.avi 
 ] current-file-size-of-matrix.avi

Well, we don't need of specific refinements, cause we can pass a 
block to read (which is converted to a port!).

>> read [scheme: 'ftp host: ... path:... other_data: ....]


The  block format could be used to pass other parameters in a more 
handy way.


>> read [ftp://ftp.rebol.com/matrix.avifile: %movies/matrix.avi]


And the good news, is that it's absolulty possible to have something 
like that now.
We just have to patch the function: system/intrinsic/make-port

Btw, you can run Cheyenne in verbose mode (-vvv or even -vvvvv), 
it's easier to debug this way. During the boot process, Cheyenne 
will list mods callback matrix allowing you to see/debug the execution 
order for your mod's callbacks.

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

Running Cheyenne with -vvvvv (should be enough) will give you a view 
of the matrix (line by line, per event) when Cheyenne starts.

correcting the agg bugs in r2 ? i would like antialiasing better 
fonts more readable less bug around the handling of font fixed etc... 
but as it just conserns my particalr and singular needs and as noone 
likes me i think i can forget it .... a bugfix to agg matrix  would 
be  nice too .. I know i'm such an egoistic being etc ...

instead of [ pen 0.0.0 text antialised  0X0 "one text" pen 255.0.0 
text  0x20 anti-aliased " red " etc... ]  it would then nice to have 
" text antiliased black "one text " red " red " etc...]  the matrix 
push and clear should be a way too  optimise the management of segments 
of  set of draw instructions ine the  draw block.

 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...

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

or "block", "matrix" ... but I am ok with "panel" anyway ...

Board, matrix, box (that one would collide with the style name, the 
same goes for grid, table). Board sounds good, but I still can't 
see the reason, why panel does not fit ...

box, board, mosaic, matrix, sieve, die, wire, netting, tissue ... 
and the winner is - panel :-)

If this is the issue there are two solutions.

1. even now you can set the transformation matrix for example using 
MATRIX command(or other matrix related commands)  to change that

2. internally in the AGG code there is a way how to change the order 
in which the scanlines of the framebuffer are rendered in the Y-axis. 
In other words you can flip the Y axis.

We we look at this from the performance POV:

-IIRC the transformation matrix is *always* used in the graphics 
pipeline so it doesn't matter if the matrix is set to 'top-letf' 
or 'bottom-left' or whatever else. There is no performance difference.

The only difference is that if you want to change the 'origin' you 
need to put one mroe command into the DRAW dialect block. I think 
you will agree that one more matrix command in the block can be assumed 
as almost no performance penalty.

Well, even if we use the tranformation matrix the text and images 
will be upside down because that is the 'behaviour' of  Cartesian 
coordinates system.

There is no confusion, sooner or later we do reach the matrix's "there 
is no spoon" = there is no R2 - old, forgotten, boring. Do you call 
Delphi 6 not a Delphi, because you can't run the code in Delphi 2 
anymore? Does Perl 6 rename, even if different to the old generation? 
VID is a good name. Simply put version 3.x is not compatible with 
version 2.x, easy as that ... I can't see any confusion, if we talk 
about VID in R3 related channels ...

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 you have a point there ... pair! are used mostly related to 
VID ....  and as pairs in fact represents a pixel matrix you have 
dot something  numbers

Steeve Matrix are costly in computations only if you do it with a 
CPU not designed on purpose to do those kind of tasks.... But with 
a GPU it's EASY CAKE ...Question is can we be hardware ignorant or 
not ?

CARL what about -12.244x-12.21 matrix don't negative floating  numbers 
deserves their own pair! too ? ( if we are loosin time in stupidity 
why not playing to game to the core ?)

i see what a pixel is  i don't see what half a pixel could be ... 
and the reason is be able to see  those half pixels i would need 
a screen that can display when and eyes that can render them to my 
brain wich will never ever be the case in this life ... So personnally 
Carl i wouldn't be sad is matrix are rounded.

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

I will push new specification changes and fixes tonight. I have added 
a type casting matrix for all possible type combinations. I am currently 
  implementing the missing cases.

I have pushed the changes for the type casting matrix support (both 
in docs & implementation). I need to add proper tests to cover that 
tomorrow.

Kaj: you can do an explicit casting, if is allowed by this matrix: 
http://static.red-lang.org/red-system-specs.html#section-4.7

The integer! -> logic! is not free, it implies generating extra code 
for converting properly (see the type matrix). So the define won't 
generate any more overhead than needed.

Right, as-logic will inline some conversion code only when required 
by the conversion rules from the type casting matrix.