World: r3wp

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

Actually, in my stargate demo (now that I look at it again more closely), 
I layout a window face with a single IMAGE face in it. I did this 
for some technical reason I can't remember, but I tried very hard 
not to make extra faces unnecessarily.

Anyway, I use a combination of techniques. I use DRAW and face/effect/DRAW 
dialect heavily, COPY image!, image datatype "bulk-set alpha", some 
face/EFFECT dialect, and finally SHOW face.

I just tried to separate math functions like square root and arctan 
with simpler constant values and speed seams to go up a bit, but 
not to much....

Ill try to make lookup tables for all visible coordinates and see 
what will happen....

profiling:
	time0: now/precise
	(your code...)
	print difference now/precise time0

changing CHANGE/DUP to POKE gives a slight speed up, but then you 
need to scale in a different way.

I tried that..... doesn't matter to much.... making lookup tables....

i made optimizations in R3, removed change/dup , parents, temp vars, 
etc...

I also replaced repeat or for structures by loops (to avoid bind/copy 
)
It changes nothing. It remains slow.
The reason is that the script does (10000 * i) iterations

in R3, by just doing iterations and a show (no computations) it takes 
4 seconds.

Then, by just adding the square-root calcul, it takes 8 seconds (2 
times slower).

i a case like that, using rebcode for math calculus in big loops 
will be really faster

Yes, I was just remembering my efforts to squeeze performance out 
of such per-pixel frame drawing and I think Rebol interpreter is 
not fast enough for such tasks. I would use the external DLL interface 
to pass your image to a C DLL function.

We need rebcode in R3.  I understand the fact that it can cause problems 
with other parts of code but if we specifically use it where it works 
it can add a tremendous boost to performance.

agree

Read BrianH's post above (1 hour 22 minutes ago) about why rebcode 
will not be in R3.

But talk of a new "different" rebcode...

Exactly,  why not just create an updated rebcode then.

Brian's answer was more like an excuse than a reason.

:)

Sleepy time for me. I think I might try make the C DLL tomorrow.

Thanks Anton!

Ch is a good candidate, it allows to build c code dynamicly

There.... lookup table done...... speed difference obvious :)
pause after click on button is rendering first frame....

do http://www.visaprom.com/tunel.r

do you have a little gain with this ?

	repeat i 256 [
		foreach pixel lookup [
			set [pozicija red ugao] pixel
			red: red + i - 1 // 63 / 2 + 1
			p: pick pick level red ugao
			if (p > 0) [
				boja: pick paleta p
				change/dup skip ekran/image pozicija boja pixel_size
			]
		]
		show ekran
	]

its a nice refinment of code :)

maybe its faster but my pc i to fast for me to notice.... Earlier 
today I tested script on three years old laptop.... Now I tried it 
on my home pc.. (amd 5000) and its to fast.... :)

Hi. I've got a local variable "level" inside an object, defined has 
follow : "level: length? t".

If I try to print it, no problem. But  if I use "build-markup {<%level%>}", 
REBOL raises a "ERROR no-value in: level". Any idea ?

Is your build-markup call outside the object? If yes, then you have 
to refer to level as object/level (where object is the name of your 
object).

o: make object! [t: "abc" level: length? t]
build-markup {<%o/level%>}

Geomol: no build-markup is called within my object. But I forget 
to say that I use "return build-markup {<%level%>}"
I don't know if I can "return" local vars ?

return is normally used from within a function. So you have a function 
within your object, that returns what you say?

2 secs, I post the snippet

>> o: make object! [t: "abc" level: length? t f: func [] [return 
build-markup {<%level%>}]]
>> o/f
== "***ERROR no-value in: level"

heh, funny! :-)

http://clojurepastebin.appspot.com/2005

Seems like a binding problem.

This works:


>> o: make object! [t: "abc" level: length? t f: func [] [return 
build-markup {<%o/level%>}]]
>> o/f
== "3"

In fact, my html-handler instance is within another object.

Geomol: So, I have to refer to the object:/level as you told me before, 
that's it ?

The difference is, you have level as a local to your function, I 
have level as a member of the object. What do you give to build-markup? 
It's a string, right? So build-markup don't know, what you mean by 
level, I think.

Yes, I give it a string. But changing to "return build-markup {<%html-handler/level%>}" 
raises the same error.

Look at it from build-markup's viewpoint. How should it know, what 
level mean? This is a bit tricky part of REBOL, but it's also one 
of REBOL forces.

level can mean anything depending on the context.

If you write you return like this, it will work:

return build-markup rejoin ["<%" level "%>"]

Geomol: No, sorry I can't understand. level is defined one line before 
I use build-markup ( forget the print statement).

Now we force the value of level inside the string, before the string 
is giving to build-markup

You're right, it works well. But I still don't understand the behaviour.

In my last example, the string become something like {<%3%>}

In your example, the string is {<%level%>}. This is what build-markup 
see, and it has to figure out, what level mean. It can't figure that 
out, because level is a local of your function.

Geomol: you mean that build-markup is sort of blind on locals ?