J'ai fait une petite vidéo ou je fais exactement la même chose sur MorphOS et MAC OSX.
A vous de juger...

Comparaison MorphOS et MacOSX

Le pb sous MorphOS je pense que c'est plus causé par la layer.library avec le fait que ton écran utilise l'accélération 3D.
Faudrait tester sans pour voir.

Et OWB n'est pas connu pour être un monstre d'efficacité (je parle pas du code de Fab, mais bien du code commun à toutes les platformes).

Oui enfin, c'est facile de déclencher cet effet en ouvrant plusieurs *fenêtres* OWB. Chacune alloue un bitmap en vram. Donc avec cette résolution, en utilisant en plus les 3d layers, c'est clair que tu arrives au bout de la vram dispo au bout de 4 ou 5 fenêtres. A partir de là des transferts ram<->vram à très haute priorité sont nécessaires, d'où les ralentissements. Si tu avais utilisé des tabs, tu n'aurais pas eu cet effet. Et OWB est une des rares applications qui allouent systèmatiquement un bitmap vram, aussi. Tu n'aurais pas eu cet effet sur Ambient ou la majorité des autres applications (bon, avec les 3D layers, toute fenêtre alloue de la VRAM, d'où la raison de l'éviter sur mac mini).

Donc bref, c'est un test un peu instrumenté. Je peux aussi faire pareil dans un autre registre sur osx en lançant pas plus de 2 applications gourmandes, avec les 512Mo de RAM que j'ai... Avec le Swap ram<->hd, il va ramer à mort aussi (et encore c'est limite plus favorable, car le transfert ram<->hd est probablement plus rapide en lecture :)).

A noter aussi que je pourrais facilement éviter d'utiliser un bitmap vram pour owb, au prix de la vitesse. Et là tu pourrais ouvrir une 50aine de fenêtres sans aucun souci aussi (sans les 3d layers, du moins)... :)

[EDIT]

D'ailleurs ça m'a pris 2 minutes à faire, donc: http://fabportnawak.free.fr/temp/owb.bz2 (tu décompresses et tu remplaces juste le binaire d'OWB).
Tu ouvres un shell au préalable, tu tapes:
setenv save OWB_LOW_VIDEO_MEMORY_PROFILE 1
Et après tu lances OWB, et tu retentes ton expérience (avec le enhanced display désactivé, de préférence, sinon ça atteindra forcément la limite de toutes façons).


@Yomgui

ça n'a pas vraiment de rapport avec webkit dans le cas présent. :)

Merci pour l'explication technique Fab.

J'ai fait cette comparaison car je me trouve souvent dans cette situation (sans forcement ouvrir 4 OWB) des fois 2 suffisent avec d'autres applis...et c'est un peu agaçant...

Il n'y a rien d'orchestré, j'ai voulu juste faire un test "mesurable" et similaire sur les 2 OS sur la meme machine...

@Fab: ?? bah si on parle de la même chose: layer 3d, mais je rajoute qu'OWB est aussi gourmand.

Yomgui,

oui, mais en l'occurrence, la partie générique de WebKit/OWB n'impose pas de consommation particulière de video ram (qui est finalement l'objet de ce test), c'est juste mon implémentation qui alloue un bitmap vmem par fenêtre. Par contre question RAM, lÃ, oui, il est très gourmand. :)

Et les onglets, ça sert à quoi ? ;-)

--
/me pense en effet que la conso de ramz d'OWB le met dedans....

jamais essayé OSX.... comme ça je peux pas voir la différence :-b

Sur la même machine et sans activer ralentissement3D (faut etre fou), je peux ouvrir en à peine quelques secondes 80 fenêtres OWB sans jamais bloquer la souris ou le son (MPlayer, pas cette bouse d'ANR qui coupe pour un rien).

Côté ralentissement3D, c'est vrai qu'OSX a l'avantage d'être linéairement lent tandis que MorphOS oscille entre rapide et inutilisable suivant la mémoire vidéo disponible :)

En effet Hernes...sans l'Ehanced Display ça va beaucoup mieux...

Comme je viens de changer de disque, j'ai gardé cette option activée (disposant de 64MB de Vram) et OSX ayant aussi ces effets (ombres, genie etc) mais je crois que meme avec les 64MB ce n'est pas la peine d'y penser :-) ce qui est domage... car niveau visuel les ombres sous les fenetes c'est quand meme sympa...

Par contre ce soir, si on veut aller voir le nouvel iPhone sur le site d'Apple, on click sur "voir la video" et OWB est dans les choux...99% du CPU...