World: r3wp

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'?

My suggestion was three keywords: hint, hint-x and hint-y.


Then you would first provide your scaling transformation, say 0.1. 
Then you provide your shape, and then add hint, hint-x or hint-y 
on each coordinate individually. Those would then be hinted to the 
nearest whole pixel internally.

Well, just turn of Antialiasing

 No. The difference between this and turning off AA is that you can't 
 make hinted rounded rectangles with AA and you can't get a pretty 
 hinted rounded rectangle without AA.

one second.

http://rebol.hmkdesign.dk/files/r3/gui/094.png

It works for the round .r icon, because it's easy to control the 
size of each filled circle, but not for the octagonal icon at the 
bottom.

also the triangle is troublesome

can you provide the DRAW data for the octagonal/triangle icon? I'd 
like to try something....

That was an SVG converted to DRAW, but I'll see what I can find.

need to get some food, back in about 30 minutes

ok,no hurry...

its usually better to generate larger shapes and scale them down, 
this way you have sub-pixel precision when drawing.  all you need 
to do is scale the widths and transform the coordinate space when 
you draw...

Maxim, we could have subpixel precission without the scaling trick. 
We just need to push Carl to make PAIR! to support decimal values 
;)

yep... just noting how to do it currently.

I would also like tuples with a bigger scale.  something like 16 
bit color values...

or even 64 bits, for float or HDRI, shadow maps, etc...  image manipulation.

(that's bits per channel)

for me the draw stroke persistence, is mainly for allowing interaction 
between the application and the graphics... text on curves... spline 
paths for animation, snap to edge, etc.

with two splines and enough information gathering, we can easily 
render bending geometry and stuff like that... right now... its highly 
complex, and we can use the internal AGG binary math to calculate 
all the coordinates to stuff for us... based on the current transforms, 
and stuff.

and we can 
 = "since we can't"

for me its not speed as much as massively usefull (and free) functionality.

Cyphre, posting privately.

So, do we write View/GUI enhancement proposal? :-)

A View proposal would be good, but we need to compile more information. 
We already have the GUI proposal.