World: r3wp

I would look for uniserv anyway, if i can run demons and need speed.

demodularisation - how do you czechs speak? Me german would think 
de -> opposite of. (Of course its a bit nitpicking for fun ;)

:-)

time to sleep, 0:41 here and I don't believe rebol has already fixed 
timezone problem, so actually who knows what is the correct time 
:-)

SDK 2.6.2 released

It seems, some of the DRAW bugs are solved in the View coming with 
the new SDK, but rebcode is not included, afaik.

and windows now stay infront as supposed to.

The icons in Canvas looks strange with this new rebview.exe. I wonder 
why!?

hmm... the rebview.exe is 33 kB bigger. that's quite a lot?

Perhaps they left the debugging code in by mistake??

huh? Did View have Convolve functions for image processing? There 
is a very fast convolve demo in the desktop now

under demos

Its new. noted in rambo.

geomol, something new to add to Canvas :-)

And just for Pekr .. a button to disable auto-connect on start up!

seems the rebol/services guestbook demo is broken now... shouldn't 
we move to a different group, btw?

WHy? isnt the sdk-christmas-tree here? :)

Guestbook works for me.

Of course, I had a guest book in my rebsite years ago :)

it seems to be a bug in the scroller. if you move it before the guestbook 
is loaded, it craps out

Ahh... see it too now.

not asynchronous

I found out, why the icons in Canvas look different with the new 
rebview.exe coming with the new SDK. Before the SCALE command in 
DRAW didn't influence LINE-WIDTH, it does now.

I also see differences in the pixel-precision, when using DRAW. It 
seems, Cyphre's changes to DRAW are included in this release.

yes, line-width scales now.

Henrik - IIRC Cyphre did convolve as an Rebcode test - but as rebcode 
is not inside, I expect currently convolve is in-built ...

it is imo way faster than even rebcode ... pity rebcode is not c 
level speed :-)

and as for strange colors, Geomol, I thought I have modified my monitor 
settings, but I do remember bubbles in demo were of slightly different 
colors

was there any tweaking to color schemes or such?

it seems more dark or so ..

hmm, the same, sorry, different quality LCDs here ...

If you look at source, you can see that 'convolve effect has been 
really added. Nice. I can't wait for change-log for 1.3.2

pekr, I saw the rebcode test, and yes, the version in 1.3.2 is extremely 
fast compared to that one...

well, it is C against rebcode ...

makes you think a bit. :-) still, I did a gauss blur convolve in 
plain rebol code vs. rebcode and the rebol version would have taken 
a full minute to process the image, so rebcode is much better than 
nothing :-)

Guys, please be patient ;) I'll post DRAW change summary in AGG group 
very soon.

BTW the new convolve function is written directly in C. Carl liked 
the rebcode convolution demo so he decided we should add this effect 
at native level.

From my quick tests the C version of convolve is about 15-25 times 
fater than the rebcode version. But this doesn't mean that rebcode 
is always 20time slower. It depends on the application imo.

yes, I noticed it, as I played with original rebcode versin a bit 
.... I thought for a little while - cool, they speed up rebcode, 
maybe kind of compiler inside? :-) and then I realised I am running 
official release, without rebcode inside :-)

I hope Carl liked also faster blitting, so hopefully this will be 
included one day too :-)

I think the biggest bottleneck in Rebcode convolve version is extracting 
32-bit integer(pixel) into R G B A parts. We probably need some opcode 
for that. I think this could speed up the 'per-pixel' operations.

or we need plannar gfx like on amiga? :-) just kidding ...

hmm, such opcode would not be traditional asm opcode, otoh rebcode 
it rebol dialect, so - why not if found usefull, right?

I think blitting is already in the todo list so stay tuned ;)

is blitting using just new/faster routines, or has in anything in 
common internally with how fast you can enter event loop (time wise), 
to call 'show?

hmm, probably wrong question ... it is not probably timer related, 
so must be faster redraw routines ...

Cyphre, I wouldn't mind having a few more opcodes that are really 
optimized for pixel writing as opposed to general purpose opcodes 
that are "sort of fast" :-)

(pixel reading too)

Henrik, please put your rebcode pixel access opcodes ideas/enhancements 
into Rambo as a wish. This could make bigger attention to Carl ;)

hmm... I don't know much about it. I think I will discuss how it 
should be done first in the rebcode group.