World: r3wp

It crashes for me when image height is > ~175

Btw, here are the reasons there won't be a compatible rebcode forr 
R3:

- R3 function parameter and local word references are 28% slower 
because of new function word model.

- R3 function calls are much faster because of typesets and the new 
function word model.

- There's a *lot* more natives, including all of the loop functions, 
iirc.

That first one would slow down rebcode even more than functions because 
even more of its overhead is word references. The last two mean that 
REBOL code will be a *lot* faster, so the relative speedup of rebcode 
is less.

Vladimir - I wonder if you checked demos in Desktop section of Viewtop? 
Go to rebol.com and then Contest folder. Look e.g. at Cyphre's demo 
called Quick Hack ...

Those reasons are why R2-style rebcode isn't worth the trouble to 
make in R3. What *would* be worth making would be a *different* rebcode 
that would be even faster :)

Anton, it crashes under R2?

no no, under R3, of course.

ah, good. I mean, bad. :-)

We can still play with R2 graphics until R3 stabilizes.

BrianH: could that work as a plug-in for e.g.? Or - do you think 
it is possible to have even several VMs that way? Simply a compiler? 
Maybe we could even find some small C compiler to be included with 
REBOL? (if that would make sense)

Right. Wait, it's up to 175? When last I checkede it was 89.

Maybe it is an easy fix? Well, I think that Cyphre is back to project, 
after Carl syncs his sources with him ....

last I checked, I needed only about 5x5 pixels.

Pekr, with plugins and utype! you should be able to use TCC to complile 
functions :)

I have my coffe and code now runs twice smoothly than first version 
:)
www.visaprom.com/tunel.r

And I tried that size trick:   view layout [image img (img/size * 
8)]
and speed is the same.....

what is TCC?

Tiny C Compiler. I don't have the link handy on this computer, but 
google it.

vladimir, try to use REPEAT instead of FOR. REPEAT is native.

http://en.wikipedia.org/wiki/Tiny_C_Compiler

Thanks. I found original site. Well, 100KB to have cross-platform 
compiler? Nice. It will not prevent devs to write cross-platform 
code, but those who would like to do so, could do so, and that is 
important ... Licence - LGPL, so it might work OK as an extension 
...

Plus you could use C as an intermediate language for a REBOL dialect 
if you like.

I think change/dup is pretty fast at setting blocks of pixels. The 
bottleneck must be somewhere else.

yes, got the same prob in R3, it's slow

making some of those calculations more rebolish might help a tiny 
bit. ultimately SHOW will be the factor.

you could remove the show and see how much faster it gets by printing 
a value to the console.

It would be nice, if we would have direct access to datatypes from 
C level. Dunno if plug-ins or rebin can provide us with such functionality. 
E.g. manipulating images was rather easy, as its structure is just 
RGBA pixels (bytes), but access to something like Block would be 
probably rather tricky :-)

Henrik - are you talking about R3 show?

no, R2 SHOW.

We'll see, Pekr. That is still being decided.

I think you could gain some speedup by not multiplying the image 
by 4, but let DRAW scale the image on SHOW.

this requires some changes in the layout.

in R3, replace the code (at tail) by: 
screen: system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]

pixel_size: 1x1
grid_size: 160x100 
img: make image! probe gob-size: (grid_size * pixel_size)

append screen ekran: make gob! [offset: 50x50 size: gob-size draw: 
[image img]]

do [
	boja: pick paleta 15
	change/dup skip img 0x0 boja grid_size * pixel_size
	for i 0 127 1 [
			for yy -50 49 1 [
				for xx -50 49 1 [

     rr: square-root (((xx + 0.5) * (xx + 0.5)) + ((yy + 0.5) * (yy + 
     0.5)))
					if ((rr > 14) and (rr < 50)) [
						zz: (900 / rr)
						pozicija: (pixel_size * (grid_size / 2 + (as-pair xx yy)))
						dubina: :zz - 18 / 46
						red: to-integer dubina * 63 + 1
						red: red + i
						red: to integer! red // 63 / 2 + 1
						either xx = 0
							[ugao: arctangent 999999999999]
							[ugao: arctangent (yy / xx)]
						either xx >= 0
							[ugao: ugao + 360 // 360]
							[ugao: ugao + 180]
						ugao: to-integer ugao / 360 * 63
						ugao: ugao // 32
						ugao: ugao + 1
						p: level/:red/:ugao
						boja: pick paleta p
						change/dup skip img pozicija boja pixel_size
					]
				]
			]
			show ekran
	]
]

and then you can also do bilinear scaling.

i wonder why it's so slow

wow, SHOW is far from the bottleneck.

Uploaded a version with repeat.... speed is still similar to previous 
versions....

yep, with R3 it's slow too

Vladimir, I can't tell from the loop, but are you drawing 1x1 and 
upscaling or 4x4 pixel blocks?

1x1 + upscaling

see that, i do a scaling in R3:

screen: system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]

pixel_size: 1x1
grid_size: 160x100 
img: make image! probe gob-size: (grid_size * pixel_size)

append screen ekran: make gob! compose [offset: 50x50 size: (gob-size 
* 4x4) draw: [scale 4 4 image img]]

do [
	boja: pick paleta 15
	change img boja grid_size
	for i 0 127 1 [
			for yy -50 49 1 [
				for xx -50 49 1 [

     rr: square-root ((xx + 0.5) * (xx + 0.5)) + ((yy + 0.5) * (yy + 0.5))
					if ((rr > 14) and (rr < 50)) [
						zz: 900 / rr
						pozicija: grid_size / 2 + as-pair xx yy
						dubina: zz - 18 / 46
						red: i + to-integer dubina * 63 + 1
						red: to integer! red // 63 / 2 + 1
						either xx = 0
							[ugao: arctangent 999999999999]
							[ugao: arctangent (yy / xx)]
						either xx >= 0
							[ugao: ugao + 360 // 360]
							[ugao: ugao + 180]
						ugao: to-integer ugao / 360 * 63
						ugao: ugao // 32
						ugao: ugao + 1
						p: level/:red/:ugao
						boja: pick paleta p
						change skip img pozicija boja 
					]
				]
			]
			show ekran
	]
]

I draw 4x4 pixels in image for each pixel I calculate.... and thats 
not slow....

I just tried an improvement that halves the drawn pixels and speed 
is the same...

I won't bet on it, but looks to me like show is the limit... its 
not the first time....

But on the other hand, this slowness gives me right speed to see 
whats going on and to check if algorythm is correct...

I dont even have to make some kind of slowdown loop :) less code 
to write.... :)

Yes, but if you want your code to run faster? :-) (which is what 
we usually want)

yes... if Im going to make a game in rebol out of this, then the 
speed is a must :)

ufff.... demo from contest wont run..... Im on Ubuntu right now.... 
it cannot open sound.....

The layout produces a face hierarchy like this:

	window face
		IMAGE face
		BUTTON face


So that's two faces needing buffers refreshed whenever you do SHOW 
window.
It's faster to have just one face (the window face).

	window face

So do as I do in my stargate demo.

vladimir, by replacing SHOW with prin '. the framerate is roughly 
the same, so SHOW is not the limit.

layout [
	backcolor black
	origin 0
	ekran: image
]

also you don't need SHOW on 'window, but only 'ekran.

aha..... I put show on 'ekran and speed is the same.... 

If Henrik's observation about replacing Show with prin... and that 
speed is the same... there is no need to mess with layout :)


Is there some way of time profiling code ? how to find out wich part 
is slowest?

By the way this script I want to use to make lookup tables for maping 
tunnel 3d coordinates onto screen so when I make those tables I can 
see if math is causing the slowdown....


And question for Anton, what did you use in your "Tunnel" demo.? 
show, direct image manipulation? or just effects for image datatype 
?

in R2 you can only do that by making differences between time stamps

but you only have roughly 1-10 ms precision