World: r3wp

There seem to be a small anomaly, when doing thick circles and ellipses, 
in the right side, where the circle/ellipse starts and ends. It may 
have something to do with "line-cap round", but if that is left out, 
there will be a tiny gap, when drawing really thick circles/ellipses.

Maybe Cyphre should check it out!?

I changed BITMAP-SIZE to 1024x768 and as I suspected it really slows 
down now...

it could be a graphics driver problem, but I also tried it on my 
linux laptop and it's also very slow there.

Henrik, it must be something special with your setup, and you get 
slow console output on the
do http://www.rebol.com/speed.r

speed-test, as we talked about. You could post your speed output 
here somewhere and specify your setup. Maybe others have a solution!

Console:   0:00:16.274 - 31 KC/S
Processor: 0:00:00.631 - 1369 RHz (REBOL-Hertz)
Memory:    0:00:01.943 - 24 MB/S
Disk/File: 0:00:01.121 - 27 MB/S

I have an ATI Radeon 9500 graphics card with the latest Catalyst 
drivers and the test is run on a Celeron 2.6 Ghz PC with 640 MB of 
PC133 memory

adding a framerate limiter in your code helps nothing

but I've always had this problem that painting large surfaces in 
REBOL takes a long time on my machine and it doesn't really matter 
what drivers I use

I get:
Console:   0:00:01.703 - 297 KC/S
Processor: 0:00:00.406 - 2128 RHz (REBOL-Hertz)
Memory:    0:00:01.344 - 35 MB/S
Disk/File: 0:00:00.203 - 150 MB/S

on a 2.4GHz Pentium 4, 512 MB ram (not sure about speed, it's an 
ASUS P4P800 board), ATi Radeon 9600, not the newest drivers.

ok, I take back the part of the framerate limiter :-)

try this: http://hmkdesign.dk/rebol/canvas.r

ah... it's dangerous, because it misses events on my slow laptop 
now, but drawing is much speedier on my "broken" PC

Well, it's a work-around, if you have slow graphics.

I've put a limiter on SHOW so that it only shows every interval, 
but doesn't miss as many position samples. so even though the framerate 
appears slow, it's actually very responsive. it's SHOW that's the 
killer.

Oki doki!

sorry, it only shows every X interval... adjustable in the display-canvas 
function

We have to see, when there is more stuff in the program, if I should 
put in such a mechanism.

ok, looking forward to see some progress :-)

:-) Just fixed a bug with line tool, if start and end point is the 
same. Well, that's progress! ;-P

alright. :-) would it be hard to add straight X/Y line drawing with 
the shift key?

:-D Didn't remember that before now. I'll check it on my Amiga...

Hmm the feel function "over" doesn't get an event, but engage do. 
Shift can be checked with event/shift.

So it's possible to have a functionality, where you first press the 
mouse, then shift, then move the mouse.

I don't think shift first, then mouse button, then mouse move can 
be handled like in DPaint. :-/

Because you might move the mouse a bit after shift, before mouse 
button.

It might be doable with the feel function "detect".

Speaking of shift, wasn't the cirlce tool actually an elipse, and 
holding shift created the same x-y offset, same with rectangle tool. 
Shift made a square?

In DPaint IV on my Amiga here, circle and ellipse are 2 tools, and 
shift has no impact, but you're right with rectangle being square, 
when shift is down. Implementing that...

Done. New version uploaded.

tegneprogrammet er dog stadig meget sløvt

whooops, wrong group

Geomol, I don't see why you can't wait for the mouse down before 
deciding on the axis direction. If shift happens to be pressed when 
you get the down event, then you enter "shift-down" mode, and on 
subsequent move events, either shift is pressed, so decide and "quantize" 
to a horizontal/veritcal direction, or not, so allow any direction 
as usual.

Anton, yes, that is a solution, but

being able to have sticky coords at all time is good. Let's say, 
you want to draw a line aligned to another element, but at the other 
side of the screen. Then you first move the pointer to the element, 
press SHIFT, move to other side of screen and start the line. I've 
implemented it via the "detect" function. New version uploaded at 
http://home.tiscali.dk/john.niclasen/canvas/canvas.r

Instructions at: http://home.tiscali.dk/john.niclasen/canvas/canvas.html

It's possible to press or release SHIFT at any time, also e.g. doing 
an ellipse to freeze height or width of ellipse before finishing 
and rotating it.

OK, where's the Right mouse erase function? : ^)

Coming up... :-)

Ok, I see. I thought it was trying to be like the dpaint functionality 
as I remember it. Perhaps you can use control for that.

In DPaint, you can use shift at all times aswell, also before clicking 
with mouse.

james_nak, uploaded new version with right-click for drawing black. 
I'll wait with possibility to choose right-click color, until I do 
GUI.

Thanks. I'll try it right now.

james, try drawing circles with this version and then try this one: 
http://hmkdesign.dk/rebol/canvas.r

Which one is faster?

Henrik, the latter is faster. It is most obvious with the draw command 
and very rapid mouse movements.

do you have fast or slow hardware?

Geomol, the Right click is most familiar! Cool.

1.8 Ghz 512MB and I haven't rebooted Xp in a while.

then the patch is mostly visible on fast machines...

Henrik, I've implementer your display-canvas, but with 50 FPS as 
the original PAL Amiga.
New version uploaded.

Hmm no good is some cases. Drawing lines sometimes doesn't show the 
end result. I think, some "show canvas" should be forced. I'll check...

Event filtering is difficult. Have you seen Gabriele and Romano's 
work on that ? Look for eat.r  and there is another one too..

New version uploaded with forced "show canvas" for all but "over" 
functions. Testing needed!

you could probably force a show canvas every time you receive an 
'up event