World: r3wp

it usually renders up until the error occurs

that's not what i got.
i got a blank screen when an error occurs.

it depends on the error... its the same in R2.

yep it depends... Brian"s heisenbugs are everywhere in draw

well, it should do the same in R3. at least it did in earlier builds, 
but does PARSE have anything to do with that?

why parse ?

doesn't DRAW use the other fast dialect making parser? don't remember 
its name.

delect

yeah that its.

meant... yeah  that's it...

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

steeve is working on annimated splash screen logo animated in svg 
for the next version of viva-rebol :P

rebol even our splash screen are ass kickers ;P

i'm fighting with several e-commerce solution (free ware) for a client 
i want to die ... how can web 2.0  without rebol can be such a pain 
T___T

Oscommerce, thelia, virtuemart, prestashop, magento, zencart, OSCC 
... have cool back offcie cool functionnalité but when you don't 
want to fit to the header, menu, left_col, document, right_col, footer 
design  you are face big troubles allmost all the engine in those 
product is to be remade....

why clients wants those shits ???? 

because they read that apache + php + mysql + ajax/css  was the top 
of  art .... yurk ...

can't anyone shake that area and put rebol in it ....  something 
like a rebol os-commerce all strong and mighty in 200Ko ... Ok you 
can go to 2Mo last limit... lol

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

congratulation steeve anyway  ^^

on my computer your annimation is lighting fast ... (maybe too fast) 
it's a very lively lizar lol

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]

REUSE might run into problems with multitasking. Ladislav has talked 
about adding a native atan2.

Probably should be implemented with a closure!

Yeah, a closure that returns a function is a good pattern. However, 
a closure by itself won't reuse the block. It's the reuse that is 
the problem - the block probably won't be task-safe.

To be task safe, the module should reinitiate the function like this:
reuse: make :reuse []

Obfuscated thing

or with
reuse: copy/deep :reuse

Then you aren't reusing, which is why it will be task-safe.

but it has to reuse the same block, in a context

n

no

not globaly

That reuse is what won't be task-safe. Only non-modifiable series 
will be sharable.

hmm...

Unless you do locking or something.

Fortunately, "or somethoing" includes wrapping a server task around 
your data. Shared service rather than shared data.

(stupid keyboard)

Nice work Steeve! I'm glad R3 gradient improvements in DRAW were 
useful. It shouldn't be a big problem to render SVG using R3 draw. 
Bigger issue is to be able to parse all the possible SVG content 
you can find on the net ;-)

Hello Cyphre, good work, you've done with gradients.

But...

My, my, my...


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

1/ The "objectBoundingBox" units.

Which means, coordinates and lengths are ratio or percentages. 

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

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


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

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

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

2/ Outlines with gradients


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

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

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

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


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

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

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

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


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

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

IIRC Henrik requested gradients for lines, so actually 2) might be 
usefull too?

yep it would help

re 1/

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


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


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

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

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

Cyphre, Maxim has also had some ideas for manipulating draw elements 
directly very quickly. Have you been in contact with him regarding 
those ideas?

Henrik, I don't think so. We had some discussions about this long 
time ago but not recently IIRC.

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

Ok, so you need the 'bounding box' , got it. I think this can be 
added...for example as special refinement of DRAW native command?

BTW I remember I also wanted to be able return all generated pixel 
coordinates of any DRAW defined shape. That can be also very useful.

i would prefer a silent functions which actually doesn't draw anything, 
but only returns the coordinates of the bounding box, or the coordinates 
of all pixels de traw (good idea btw).

COORDINATES draw-block.

return a block of pairs (coordinates) of the pixels to draw 
Carefull, may be really huge.
Perhaps a mask is better (an image or a bitset)

COORDINATES/BOUND draw-block

return only the min-max coordinates.

Well well...

Ofcourse, the DRAW function wouldn't draw anything in case of using 
such refinement so no need to worry...I bet Carl will make the last 
decision about the wording and I know I'm not good at it so...yes 
something like that ;)

Will you  transfer the request to Carl ?