World: r3wp

Yes, Gabriele is right. No big changes to DRAW at the moment. We 
wanted  to make sure the new compiler and string change doesn't break 
any actula feature of DRAW so the decission was no changes to AGG 
until we are sure it works the same like in 1.3.2.

Geomol: The behaviour of LINE you have spotted is not a bug. Try 
this code to see the difference:

view layout [
	origin 0
	box 400x100 white effect [
		draw [
			pen red
			line-width 15
			line-join round
			line 10x10 90x10 90x90 10x10
			spline 110x10 190x10 190x90 110x10 
			spline 210x10 290x10 290x90 210x10 closed
			polygon 310x10 390x10 390x90
		]
	]
]

Which of those should have round corners?

Hmm, when comparing 1.3.2 and 2.7.4: The LINE-CAP round has no effect 
in 2.7.4?!? Looks like a bug.

Cyphre, you should make sure, Carl is using the right DRAW source, 
when building for OSX.

Geomol, to explain it a bit:
LINE - draws single lines (eve if you specify multiple coords)

SPLINE - draws 'connected' lines but the 'head' and 'tail' is splitted 
(until you specify CLOSED keyword)
POLYGON - always draws 'connected' lines in form of closed shape

Thanks! :-)

I think, I should use SPLINE in stead of LINE in some of my scripts.

LINE - shape of 'head' and 'tail' is affected by LINE-CAP mode

SPLINE - shape of 'line joins' is affected by LINE-JOIN mode...if 
CLOSED is defined shape of 'head' and 'tail' is affected by LINE-CAP 
mode
POLYGON - shape of all 'line joins' is affected by LINE-JOIN mode

Geomol: I'm (almost)sure Carl is using the same DRAW sources ;) What 
specific problems did you noticed?

Yes, it looks like there is no difference betwwen LINE-CAP BUTT and 
LINE-CAP ROUND in the 2.7.4 release. Can anyone confirm it?

example:
view layout [
	origin 0
	box 200x100 white effect [
		draw [
			pen red
			line-width 15
			line-cap round
			line 10x10 90x10 90x90 10x10
			line-cap butt
			line 110x10 190x10 190x90 110x10

		]
	]
]

(the first triangle should be 'rounded')

They are both NOT rounded here with version 2.7.4.2.4 Mac OSX.

Cyphre, you might wanna see my comments here: http://www.rebol.net/cgi-bin/upnews.r?view=0011#comments

Maybe you can give it better meaning, how it should work, than I 
did!?

Thanks for confirmation. Ok, so this is 'new' bug. Seems to be related 
to the new string change. I'll notice Carl about this.

Let me check your comments...

hmm, what's wrong with this?
i: make image! [100x100 255.0.0]
draw i [pen green line 10x10 90x90]

view layout [box effect [draw [image i transform 0 -30x-20 2 2 0x0 
image i]]]

Cyphre, under OSX, the transformed image has wrong colours. I think, 
the tuple is turned around. I'll make an image for you...

Cyphre, so SPLINE is most likely faster than LINE, because it's not 
separate lines as LINE is?

that' probably a endianess issue.

Ah, that is possible. There is still some little/big endian bug in 
image! datatype under OSX. I thought there is some problem with transsformation 
;)

Cyphre, you can see the transform bug here: http://www.fys.ku.dk/~niclasen/rebol/transform-bug.png

SPLINE actually seems a little faster than LINE. Interesting! :-)

It can be faster because the SPLINE is drawing line in a loop while 
LINE is called separately for each line.

drawing line = drawing lines

Thanks, for the screenshot. I already know about this problem but 
I don't have my MacMini running at the moment so I just tested the 
tranformation correctness, not colors.

The endianness bug will be hopefully fixed with some next release.

Cyphre, my goal is to get Canvan RPaint for version 1.0 and work 
the same on Win, OSX and Linux. Then REBOL/View is in a condition, 
I'll call good! :-)

*Canvas RPaint to v. 1.0*

Yes, that's good idea. Actually we have lot of DRAW tests but there 
is so much combinations so it is not easy to check all things quickly. 
So it is great you and other people from the comunity help testing 
DRAW.

(I hope I'll finish almost-fully automatized testing procedure for 
new releases. This will help us to catch some little details)

Cyphre, so if you can do anything to get text support in DRAW (under 
OSX and Linux??) and also push Carl to have prober event handling 
(something I haven't reported yet with the new Mac version), I'll 
really appreciate it. Maybe the time is now, where his hands are 
on View for OSX.

AFAIK Linux has the DRAW text support added(using fretype2 library). 
The only problem is how to get path to a font on Linux.(as there 
seems to be no 100% 'standard' way how to get it on all distros we 
need to use yet another dependency :-/ )

On OSX text...we might use the freetype2 too but I guess it will 
be better to use native API for that.

ok, I don't know much about fonts under OSX.

cyphre, has the window-to-front fix for OSX from the blog been noticed? 
someone posted a bit of code to eliminate that problem.

I haven't noticed this. Which blog comment?

cyphre: oh, Carl is talking about a focusing problem, but it would 
be the same thing: http://www.rebol.net/cgi-bin/blog.r?view=0157

Hmm, don't know if Carl noticed it. I'll let him know to be sure.

btw font handling paths in linux is a problem for all apps... not 
just REBOL.

many apps have an explicit config telling it where the fonts are... 
so they can be auto resolved afterwards.

why not just have that extra parameter setup as a global word ?  
then it can be setup within user.r if need be.

Yes, that is also possible alternative. We need to decide the final 
solution soon. Anyway, any useful ideas from 'Linux gurus' are appreciated.

Geomol: I have found what is the problem with LINE-CAP...it works 
with ROUNDED keyword instead of ROUND. I need to check with Carl 
why he decided to use ROUND for LINE-JOIN and ROUNDED for LINE-CAP....

(looks like a typo to me)

hehe :)

Should be easy to fix, so that's good.

Script to test events: