World: r3wp

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 ?

I think it should be stored in R3's bug/wish tracker. I don't think 
graphics is Carl's priority right now.

We should put it into View proposal I suggested to create ...

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

also it would allow us to get information about the strokes   

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

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

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

but it means the internals need to have a persistency added to them, 
which definitely changes the architecture.

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

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

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

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

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

what about caching of results?

If you are talking about caching of the coordinates....that was my 
question. For small(simple) datasets this can have almost no effect 
so bitmap caching would be much efficient in such case. For bigger(complex) 
datasets there can be performance gain(but this needs to be proved 
by some experiments).

The persistency Maxim mentioned is about caching the previous internal 
data. But question is if this should be driven by GC(no need to care 
about it from the prog. POV - but can lead to higher memory consumption) 
or by developer (programmer have the full control on it - but can 
be tricky for beginners...but yes, we are talking 'advanced' feature 
here ;-) )

About having gradients for lines, this for me would be a solution 
to the problem that complex drawings that scale, can't be hinted 
properly. I saw this when making some icons for R3 and then scaling 
them. At 1:1 they look fine, but lots of detail is lost, when they 
are scaled down.

For some reason, hinting is going to be hard to implement for DRAW. 
I talked this alot over with Gabriele, who felt it was not possible 
to do. It would still be very nice to have for truly scalable GUIs.

Henrik, how could gradients for lines help with downsaclin of vector 
shapes? Can you show me example of the 'downscaled icon'?