World: r3wp

Easiest way to find all the posted results:
    http://www.rebol.org/aga-search.r?q=disk/file

cool :-)

Pekr: AGG is very quick  which is why it renders so nicely but it 
is all CPU bound (no h/w accel) -- I would appreciate a benchmark 
because I think we should be compiling AGG with -O3 given it is C++ 
code heavy on templates

ssolie: here you can download simple benchmark: http://cyphre.mysteria.cz/tests/gfx-bench.r3

my result on WinXP SP3 ,Intel Pentium Mobile 4 1.8Ghz, ATI Mobility 
Radeon 7500, 1GBRAM

0:00:17.916 22.326 FPS

Win Vista, 32 bit, Dell Latitude D830, 2GB RAM, Intel Core 2 Duo 
1.8:


Script: "Host-Kit Graphics: Basic gfx benchmark" Version: 1.0.5 Date: 
none
GFX benchmark result
0:00:08.044 49.726 FPS

BTW my internal unoptimized OpenGL accelerated version on the same 
machine as above ;)

0:00:08.342 47.95 FPS

btw - I read some OS-X/Flash related discussions on OSNews, and it 
seems Adobe is being criticised for not using new API. Is that Cocoa? 
Now as we have R3 library available - will we target this environment? 
IIRC R2 did not use it?

People who criticise Adobe for not using the new API don't realize 
that it *does* use the new API now. It's just that the API was only 
released recently, and was done badly.

Done badly by Apple, not Adobe.

Then how can it be that every single other video player under OSX 
performs at least twice as good, CPU time wise, as flash?

Because they don't use the API, they use their own code.

Also, Flash sucks for reasons that go beyond video rendering. It's 
not all Apple's fault.

Then it means that R3 should use its own code as well. But I think 
it's not an easy answer. Everything I hear about the flash implementation 
on OSX is heresay.

Agreed, especially to the hearsay part.

Some say that video is based on an inefficient color conversion process. 
Others say that Flash uses a really stupid polling mechanism. I think 
there is a garbage collection issue, but that is again hearsay.

Nevertheless, I don't think R3 would have issues with this, as long 
as it's done properly.

I know that some things in the Apple APIs wrt access to the hardware 
where never opened up and could only be used by apple themselves. 
 its possible that some people figured out how to hack their way 
through this, but flash is embedded in a browser, so probably can't 
since there would be some executions conflicts between the browser 
and the plugin.   


just a guess, but when you compare flash to other adobe apps, I can't 
see why flash would be left in perpetual agony when their other software 
doesn't have these issues.  in fact, for years Adobe apps where the 
fastest ones on Apple HW.

Maxim, tried Adobe Reader or any Air apps on OSX lately? :-)

ok, Air is flash, but still...

I was referring to their "professional" apps.

I always wondered why reader was so bad on OSX.  but is it really 
need since we have the internal OSX pdf reader.

Well, there should be no problem for us yet, no? So far, R3 uses 
SW rendering, there's not much to worry about in regards to OS-X 
API, no? Later on, as we have proper codec system, or we try to accelerate 
gfx or video, it might be a different topic.

My personal opinion is that Adobe is too big now and they probably 
don't understands it's own code. Especially the one which acuired, 
like Flash from Macromedia.

Also don't forget that Adobe and Apple are not friends anymore.

yep. in fact ever since Apple starting selling "high-end" apps they've 
done everything in their power to hurt their most direct software 
competitor.

1ooo cows do not work? Time to rewrite cow as R3GUI style!

If everything goes well we could use the OpenGL on OSX to render 
R3 graphics so my guess is R3 performance shouldn't be so bad.

yes, it does not work. Cyphre's gfx test works though. I am interested 
in Amiga figures :-)

Pekr, I'll publish r3.exe with the opengl rendering by monday. I 
wonder how much fater will be the benchmark script on your machine 
:)

fater=faster ;)

BTW last night I added freetype font rendering to the hostkit so 
ssolie will be able to try render text on AmigaOS4.

yes, my machine is 4 years old Dell notebook, and the test was as 
fast as your OpenGL accelerated one. You really have to have an old 
machine, no? :-)

Freetype? Is that for Linux and other, non-windows OSes?

yes, thats more than 8 years old thinkpad notebook..I prefer to test 
performance on olde machines..it shows the bottlencks much easier 
than on some hi-end supercomputers.

Feetype: by this addition in the hostkit we can theoretically get 
font rendering on Amiga, Linux, OSX etc. For OSX it would be great 
to switch to native fonts(Quartz?) later though.

BTW It's a shame that AmigaOS will have View sooner than Linux! It 
looks like the Rebol comunity have no Linux 'power programmers', 
or noone needs View on Linux?

None serious Linux programmers would touch any non-GPL stuff ;)

yes, it is a pity. But mabe even more so - maybe many ppl would welcome 
View or at least Core on mobile OSes. Android and Wm6.5 are the biggest 
candidates imo ... (dunno what can be done about the iPhone)

Rebolek - really? Then why Linux folks are happy about some binary, 
non GPL drivers, etc.? :-)

Bolek: ah, you're right..I forgot about  'The Linux geek Ten Commandments' 
;-)

Maxim: "but is it really need since we have the internal OSX pdf 
reader." - I would like to say that, but unfortunately I have had 
to process some absolutely nasty PDF forms that would not work in 
anything, but Adobe Reader, due to various custom elements, encryption, 
etc. Where were they from? Our dear government, of course.

I've yet to meey any Linux programmers who have installed an open 
source BIOS.....So many of them have limits on where they draw the 
closed/open line for their software development stack. 

They and I just disgree on the best place to draw that line to create 
an appropriate marketing model for various projects (including REBOL)

meey ==> meet

Let them die in peace :-)

henrik:R3/Lobby>> help
sh: xdg-open: command not found
sh: x-www-browser: command not found
** Access error: external process failed: "Undefined error: 0"

** Where: browse parse try either either forever command-loop make 
context do catch either either -apply- do try chat
** Near: browse help-url

Seems these are broken in A110 for OSX.

Oldes - Carl seems to propose to export your requested functionality, 
if needed, so that it does not break with next internal changes. 
So please react accordingly in R3 chat = make your wish clear :-)

Henrik, opening a browser is not really implemented in the OS X port. 
The methods that are tried are Linux conventions

Kaj, it used to work, so I'm considering it a bug.

Ah, I didn't know that