World: r3wp

>> to-integer to-binary  255.255.255.255
== -1

but to integer! to binary! [issue!] is not same as rgba-to-int

OTOH the pixelformat of accesing IMAGE! in RebCode id ARGB

>> rgba-to-int 255 255 255 1
== 33554431
>> to-integer to binary! 255.255.255.1
== -255

>> to-integer to-binary  1.255.255.255
== 33554431

ALPHA is the first component

(in Rebcode)

Really?

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	poke img 1 a
]

update-pixel: does [
	do draw-pix col/1 col/2 col/3 col/4
	probe img
	show i
]

col: 0.0.0.0
img: make image! 1x1

view layout [
	backcolor black
	i: image img 100x100
	scroller 200x16 [
		col/1: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/2: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/3: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/4: to-integer face/data * 255
		update-pixel
	]
]

not if you do PICK on image!

I mean in regular REBOL code.

I guess Cyphre has a good qualification for such statements ;)

I REBOL the pixelformat is RGBA due to tuple! behaviour (you can 
left the last value of tupple == opaque pixel)

So another coversion needed :)

In REBCODE you are accessing image! internally so the pixelformat 
is ARGB.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

Cypher, have you looked at the apply problem?

not yet

There's an apply problem?

trying to reproduce the problem I've just crashed REBOL with CRASH 
Should not happen

Maybe not a problem, but overhead?

And REBOL ate all memory

can you post the code?

yes, show us!

two testing functions:

>> mulr: rebcode [a][mul a 2 return a]
>> mull: rebcode [a][loop 10000000 [apply a mulr [a]] return a]

From my tests calling a REBCODE function (or subroutine) using APPLY 
is by 100% slower than reusing the same code.

first test: xt: now/time/precise loop 10000000 [mulr 2] now/time/precise 
- xt

Is that neccessary?

second test: xt: now/time/precise mull 2 now/time/precise - xt

ssecond does has some problem

does=test

Is it neccessary to tune that, or would macro-expansion do? faster 
anyway. How big may rebcode-parts be?

hunderts lines of rebcode in my case :)

Not much memory then! But much work :)

1GB is not enough for ten milions multiplications? :)

It looks like APPLY inside a LOOP is causing those problems.

This need to be fixed.

(I meant inside Rebcode LOOP)

if I lower number of loops to 1 000 000, there's no crash and the 
difference between direct and apply version is not so big, some 5% 
(but still remember, that in the apply version, there's loop inside 
rebcode and it's way faster than rebol's loop, so apply is still 
slowing it down)

I think it eat too much memory.

It looks like some memory leak.

time: func [b /local start] [
	start: now/precise
	do b
	print ["Time:" difference now/precise start]
]

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]


draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	return a
]

draw-pix2: rebcode [r g b a][
	loop 1000000 [
		apply a rgba-to-int [r g b a]
	]
	return a
]

probe stats
recycle
time [loop 1000000 [draw-pix 255 255 255 255]]
probe stats
recycle
time [loop 1000000 [rgba-to-int 255 255 255 255]]
probe stats
recycle
time [draw-pix2 255 255 255 255]
probe stats

you can see that stats in Rebol shows 'normal' values but in the 
last test case the memory allocation under Windows increase by 300MB!!

A note about speed:
I've made an exponont function like this:

exponent: rebcode [b [decimal!] x [decimal!]] [
	eqd x 0.0
	braf 2
	return 1.0
	log-e b
	muld b x
	exp b
	return b
]

It can then be used in a rebcode function, e.g.:
apply result exponent [2.0 4.0]

An alternative way is to make a normal REBOL function:
exponent: func [b x][b ** x]
which can be used the same way:
apply result exponent [2.0 4.0]


It turns out, that using a normal REBOL function is faster in this 
example. It then occured to me, that it could be even faster, if 
APPLY was changed to support operators. Like this:
apply result ** [2.0 4.0]

Is that a good request?

I will check it

Apply doesn't support operators?

no

How well does  apply res power [b x]  work? That's the regular native 
equivalent to **.

All operators have native equivalents.