World: r3wp

so probably final version:
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
]

There might be a problem with arithmetic overflow if a < 127, as 
lsl a 24 would result in a negative integer, but I may be wrong here. 
Still, why risk it?

>> rgba-to-int 255 255 255 255
== -1

Kru, which version did you use?

last one

Cool, it works the way I thought it would :)

BTW negative integer doesn't  matter when changing pixels in IMAGE!

>> 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