> I also tried youtube with that script in the ultimate pack.
> Yea it works, but also only in 360. In 480-resolution it
> starts to drop frames and the sound isnt in sync anymore.

That's what the full-screen (or rather full-window) mode is for. You may have to use this script:

http://fabportnawak.free.fr/owb/scripts/YouTube_Fullscreen_Fix.js

With that activated, the video should play smoothly in overlay mode.

Thanks for that hint.
I'll try that!

I tried the Fullscreen-Fix and it is really much quicker. At least 640x360 (H.264 and WEBM VP8) and 854x480 (WEBM VP8) work quite nice.
Thanks.
Btw: It took me quite a while to understand the "numbers" (i guess thats the internal Youtube ID's for each resolution) under the Video.
God thanks, i found the ID-to-Resoltion Table in the Prefs-menu.
Maybe someone should replace that IDs with a Human-understandable Description instead.
Maybe i'll take a look at that youtube script this weekend. Cant be that difficult.

Anyway thanks for the hint. I didnt expect the overlay mode to be that much faster.

Regards,
engine

> It took me quite a while to understand the "numbers" (i guess
> thats the internal Youtube ID's for each resolution) under the Video.
> God thanks, i found the ID-to-Resoltion Table in the Prefs-menu.

Wikipedia has a detailed overview:

http://en.wikipedia.org/wiki/YouTube#Quality_and_codecs

@engine

In the youtube.js script that replaces Flash by HTML5, there's a description of the ids in the "preferences" link indeed.
Anyway, the reason why overlay fullwindow is so much faster is that it doesn't have to go through cairo, which makes it about as fast as MPlayer (i reused the same blitting routine, actually, more or less).

As for youtube_fullscreen_fix.js, it's meant to change the fullscreen behaviour of the custom HTML5 player of youtube (by default, they just stretch the area, making it even slower for us, so i just bypassed this and switch to overlay mode instead).

Keep in mind Odyssey/WebKit uses Cairo backend, and on our platform, it's not hardware accelerated at all. That said, i don't share your experience, it's faster than Safari in most cases.

About UAE, it seems you want to use it for workbench emulation, and in this case better use fullscreen mode, otherwise mouse handling is a bit annoying (the mousegrab option is only available in the sdl version IIRC).
Regarding file requesters for ADF insertion, i don't have that kind of trouble here.
If you plan to play games with UAE, i'd suggest using the non sdl version, and in overlay mode for a bit extra speed (amiga.use_overlay=1 or so).


[ Edited by Fab 31.08.2012 - 10:47 ]

@feb:
Thank you for that background info about OWB.
About the speed OWB vs. Safari: I have to relativate that a bit.
The Raw website rendering seems to be nearly the same as on Safari.
But when i first tested OWB, i was on Google and they do this "instant-search-while-typing" and this is really unusable slow. I can type 2-3 letters and then OWB freezes for some seconds and i cant type anything until the search results (for this incomplete search) comes up.
I definitivly dont have this behavior in Safari. Thats why my first impression was so negative.
So i guess its not the html-rendering but the javascript interpreter thats a bit slow.

Another thing i saw is that with multiple open OWB windows it really gets slow too.
Maybe a memory thing? Just a thought.

About UAE:
I first used the SDL Version because i wanted to use P96... later i discovered that this is pretty useless because it was just too unstabile.
So i switched to non-SDL but in window mode and had the issues described above.
I will try overlay mode though. Lets see if that works better.

> with multiple open OWB windows it really gets slow too.
> Maybe a memory thing?

This issue has been discussed here on MorphZone in the past. You may want to read from there:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7824&start=64
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7983