World: r3wp

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.

Like the Parse Project page, we now have a View Project page:

http://rebol.net/wiki/View_Project

Please fill in your proposals.

cool ....

Is it multicategory? I mean - all draw related stuff goes into Draw 
section? Or each request should start with blue description name? 
If you want to divide it into categories, we might need more of them 
- e.g. where to put stuff like Top Window Transparency, Multimedia 
Timers (not sure that one belongs there, but I want to have it somewhere)

Perhaps we could split it into a View Project and a DRAW Project.

Dunno - there can be many various requests, but basically it would 
be correct, although we do have Effect pipeline too, but I don't 
know, if it is AGG based, or not ....

AGG is not only about draw - it is our rendering engine too ...

I mean - compositing engine ...

I think I'll leave it for this page for now. We can split it in multiple 
pages later. Our discussions seem to criss-cross between DRAW and 
View anyway.

Henrik, have you the original svg files of the signs ?  I would like 
to see what i get with my parser.
If they are not public domain, don't give them ;-)

hehe, added first request :-)

Steeve, sorry, it's a small hack. I grabbed the svg coords from inkscape 
manually and simply pasted them in a text file, made them pretty 
for rebol and converted them to DRAW in a simple way. I have no XML 
parser or anything like that.

bug you kept the original svg files, did you ?

* but you