World: r3wp

http://www.rebol.net/cgi-bin/rambo.r?id=4086&

Look similar, seems that the 2nd argument for PEN  triggers the crash.

This is known bug, it's already in RAMBO - http://www.rebol.net/cgi-bin/rambo.r?id=4040&

bug has been fixed for 2.7.6 (will be released shortly)

That's good news

Is the AGG implementation capable of drawing filled donuts such as 
the third example in - http://www.w3.org/TR/SVG/painting.html#FillProperties

view layout [box 400x400 white effect [draw [pen none fill-pen red 
shape [move 100x100 arc 300x300 90 false true arc 100x100 90 false 
true move 150x150 arc 250x250 60 true true arc 150x150 60 true true]]]]


When I run this code under OS X, REBOL/View version 2.7.5, I get 
the effect. I find, that some of the parameters isn't logic. The 
documentation is ambigious, http://www.rebol.com/docs/draw-ref.html#section-5, 
so it may change.

hmm thanks - i often find issues between the docs and the actual 
builds with argument order

in the following example what does the 90 refer to??

shape [move 0x0 arc 200x200 90 false true]

ive experimented with various values and don't have a clue - please 
enlighten me :)

I guess, Cyphre is the one to ask.

lol - i tried values from 40 - 100 - all the same result :)

hmm.. well 60 - 100 for the outer ring, 40 - 70 for the inner ring

Maybe this give a clue?

view layout [b: box 400x400 white effect [draw [shape [move 0x200 
arc 90 200x400 false true]]] at 300x20 slider [b/effect/draw/shape/arc: 
to-integer value * 360 show b]]

From Cyphre:


Yes, the DRAW dialect  has FILL-RULE keyword which should work the 
same as described in the svg documentation. And yes, we need to improve 
the documentation and maybe even change the arc syntax. Any feedback 
on this is welcome.


BTW the ARC shape command should work according the http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands

I found ARC very difficult to use. The parameters are not very helpful.

Yes, the ARC shape command is a bit confusing....we need to improve 
the syntax or make at least clear docs on it.

I would like our agg command structure to concentrate upon compatibility 
with SVG, if possible and if it would be benefical to us. E.g. I 
remember we could not produce compatible gradients ...

is it possible to add viewport rendering into AGG?  eg virtual boundary 
limits - this would save using additional gobs/faces and simplify 
things a lot

eg: i might have an effect: [draw [viewport [any agg commands.. text 
etc....] .. viewport [...] viewport [ .. viewport []]]]

if viewport was to be done like shape - but contain the full AGG 
dialect we could do nesting.

you mean for clipping on non-rectangular areas?

no for clipping on retangular regions.. there is a command for that 
already and ive missed it havent I? ;)

hahaha clip

i cant believe i missed that

*slaps self*

was too busy looking for region / viewport / zone..

what is the viewport? I do remember it from Amiga, but don't remember 
what it was about..... kind of separate gfx space/bitmap to draw 
on?

viewport was for virtual bounded regions of the drawing screen

exactly what clip does now :) except clip doesnt set an origin

so I guess after all that I still do want a viewport ;P

altho i can be munged with a translate after teh clip i suppose

i/it

re clipping non rectangular that would be too expensive in processing 
terms.

i think AGG can probably handle non-rect clipping too.

it would be a nice effect

however... what you need is done best by just using multiple gobs. 
feel free to use hundreds of them ;)

yeah - but im worried about event hit detection - or is it a pre-composited?

events - how events are detected depends completely on you in R3

eg one face in micro vid has many gobs... and all the events for 
those gobs go to that face.

so you can have hundreds of gobs all sharing the same feel functions.

hmm, how are events tied to gobs then? With face, we had 'feel for 
that ...

or even have a single event function as event awake (you can do this 
in R2 too)

petr: by mezz code :)

and, it's fast, don't worry :)

mezz code? slow :-)

no it isn't ;)

ah, you were faster, so actually it might be fast :-)

well, if mezz code can be rebcoded :-)