CDG Contre Apple.. - Page 2

http://wiki.winehq.org/BenchMark-0.9.33 pour les benches.

Les benches où Windows se montre le moins à son avantage sont les benches disque. Rien d'étonnant, car les accès disque (avec l'horrible allocateur de blocs, notamment...) sont une faiblesse connue de Windows.
(Mais bon, cette version déjà ancienne de Wine est... euh... mauvaise sur certains usages !)

Tiens apple impose Safarti sur windows grace au couple iPod iTunes...
Je comprends pourquoi il peut y avoir des fanas du libre de temps en temps...

Oui, j'avoue que ça m'a assez gavé aussi. J'utilise Safari sous Mac mais la beta de FF 3 sous windows, et hier il m'a installé itunes + safari alors que j'avais juste besoin de quicktime...

et ça continue de fonctionner si on désinstalle tout ce dont on a pas besoin ?

je viens de tester opera sur mon ppc et il rox vraiment par rapport a saffari 3.1. Par contre sur windows.. bof bof

Zephyr (./34) :
et ça continue de fonctionner si on désinstalle tout ce dont on a pas besoin ?

si tu refuses il te le repropose après comme "mise à jour indispensable", enfin c'est ce que j'ai eu

Apple est beau Apple est grand!

JackosKing (./37) :
Apple est grand

Vu la place qu'il prend sur un disque quand on n'a besoin QUE d'un codec (et qu'il installe tout un framework et trois milliards d'outils qu'on n'a pas demandé), on peut en effet dire que c'est grand

GoldenCrystal (./13) :
Ouep sachant que le "Wine Is Not an Emulator" ça dépend vraiment de ce que tu considère. De mon point de vue d'ailleurs c'en est un...
Car tu as linux => APIs et services divers sous linux => Wine => App
Alors qu'en natif linux tu as linux => APIs divers de nunux => App
Et sous Windows tu as Windows => API Windows => App
Enfin voilà

Bah pour moi y'a aucun doute, que ce soit de la simulation, émulation, etc. c'est pas natif, donc peut être qu'on peut jouer sur les mots, mais c'est pareil (je ne connais pas les détails mais pour moi ça ressemble à de l'HLE, vu qu'il y a émulation de l'environnement: registre, etc). Et en général c'est lent, à moins que l'API implémentée dans l'émulateur soit plus optimisée. Et je pense qu'il faudrait plutôt mettre ce point en valeur plutôt qu'essayer de jouer sur les mots.
Même utiliser OpenGL sur la PSP c'est une forme d'émulation pour moi, tu simules la manière dont un GPU virtuel fonctionne, du coup tu as un overhead parce que l'API n'expose pas du tout la manière dont le GPU fonctionne vraiment (par exemple le coup du glBegin / glEnd qui doit bufferer les vertices, la manière de gérer le color mask, etc.).
Sinon perso ça me saoûle aussi que pour simplement installer iTunes j'étais obligé de me taper QuickTime, vu que j'avais déjà les codecs pour faire ça

Brunni (./39) :
Sinon perso ça me saoûle aussi que pour simplement installer iTunes j'étais obligé de me taper QuickTime, vu que j'avais déjà les codecs pour faire ça

Il me semble qu'iTunes se sert de Quicktime ^^ Apple porte ses logiciels sous windows à la barbare, et au lieu d'utiliser les API système pour avoir un truc propre, ils réimplémentent une bonne partie d'OS X... Du coup, on a un truc moche, lourd et pas du tout intégré...

./39 Ben après si chacun s'amuse à redéfinir le vocabulaire à sa façon ça n'a plus grand intérêt de discuter.

Flanker (./40) :

Brunni (./39) :
Sinon perso ça me saoûle aussi que pour simplement installer iTunes j'étais obligé de me taper QuickTime, vu que j'avais déjà les codecs pour faire ça

Il me semble qu'iTunes se sert de Quicktime ^^

Je confirme, itunes réutilise un framework quicktime par derrière... (d'ailleurs toute l'histoire de framework d'apple me tapent sur le système en ce moment, j'en suis retourné à développer sous linux/windows).

t'as bien raison

Ben si j'ai bien compris ce que les linuxiens tout fiers m'ont raconté, Wine prend un exécutable Windows et exécute le code dans un environnement virtuel (j'imagine qu'il charge les DLL et que la résolution des noms se fait au début de l'application comme sous Windows, donc du coup pas d'overhead au milieu).
Ca ne change pas que si je fais selon la vieille API Windows:

void DessineRectangle(int32 x0, int32 y0, int32 x1, int32 y1, uint32 color)
{
    uint32 colorBGR = (color & 0xff00ff00) | ((color >> 16) & 255) | (color & 255) << 16;
    HBRUSH hbr = CreateSolidBrush(colorBGR);
    RECT rt = {x0, y0, x1, y1};
    FillRect(hdcWindow, &rt, hbr);
    DeleteObject(hbr);
}

Maintenant que je fais pareil, disons avec OSLib (je ne connais pas linux, c'est pour prendre un exemple):

void DessineRectangle(int32 x0, int32 y0, int32 x1, int32 y1, uint32 color)
{
    oslDrawFillRect(x0, y0, x1, y1, color);
}

En faisant de la même manière que Windows je devrais émuler le CreateSolidBrush qui me crée un objet qui servirait à rien ici vu qu'il contient juste une bête couleur. C'est forcément moins bon. Plus haut je parlais de la différence en hard, alors voilà le même exemple mais en hard (sceGu se mappe quasi 1:1 sur le hard, et dans cet exemple c'est le cas):

typedef struct       {
    unsigned long color;
    short x, y, z;
} OSL_LINE_VERTEX;

OSL_LINE_VERTEX* vertices = sceGuGetMemory(2 * sizeof(OSL_LINE_VERTEX));
vertices[0].color = color;
vertices[0].x = x0;
vertices[0].y = y0;
vertices[0].z = 0;
vertices[1].color = color;
vertices[1].x = x1;
vertices[1].y = y1;
vertices[1].z = 0;
sceGuDrawArray(GU_SPRITES, GU_COLOR_8888 | GU_VERTEX_16BIT | GU_TRANSFORM_2D, 2, 0, vertices);

Maintenant regardons la manière de faire en OpenGL:

glBegin(GL_QUADS);
    glColor4ub(color & 255, (color >> 8) & 255, (color >> 16) & 255, (color >> 24) & 255);
    glVertex2d(x0, y0);
    glVertex2d(x1, y0);
    glVertex2d(x1, y1);
    glVertex2d(x0, y1);
glEnd();

Ca n'a purement rien à voir. Dans le cas d'openGL tu traces tes vertices à la volée, tu ne sais pas combien à l'avance il y en a (elles ont peut être une mémoire à eux comme sur DS, elles sont peut être dans une pile à la fin de la VRAM, ...). Sur PSP on les met dans le commandbuffer (display list), donc tu vas devoir détecter quand une liste de vertices commence à être tracée, sauvegarder la position du commandbuffer, puis ensuite revenir dès que tu as fini (comment détecter? => un check de plus dans toutes les fonctions qui accèdent à la command list) pour définir à cette endroit un saut (histoire que le GU n'exécute pas la liste de vertices). Note qu'on pourrait aussi stocker les vertices à la fin de la displaylist mais ça serait pas efficace si on veut la garder pour la réexécuter plus tard vu qu'elle prendrait forcément tout l'espace qui lui est alloué.
Sur PSP tu as la primitive SPRITES qui est bien adaptée, sur OpenGL tu te taperas toujours des quads, qui sont moins performants. Sur OpenGL les couleurs sont définies en 4 parties donc il y a décomposition puis recomposition (pas efficace). Bref je maintiens que dans tous les cas du moment que tu as une API différente de ce que ton système propose vraiment, même en 100% natif tu as de l'overhead car tu ne fais rien d'autre que simuler un environnement virtuel qui n'est pas celui d'origine

Justement il ne parle pas de linux là je ne vois pas le problème ^^

Et le rapport entre Wine et Apple ?

Tout ça parceque j'ai oublié le , tu prends la mouche

Martial Demolins (./49) :
Ben le rapport avec Wine alors s il parle pas de Linux?

Tu cherches un peu la petite bête là... Je suis pas forcé de m'y connaître en linux pour m'être documenté un peu sur Wine. Et un OS reste un OS, qu'il soit Linux ou Windows, là on parle de Wine quoi. Ca pourrait aussi tourner sur OS X ou n'importe quel autre OS ce machin (même Windows à la limite ), le principe reste valable.

Non.

Génial vous en avez d'autres des arguments constructifs comme ça vous deux?

Oui :

Brunni (./54) :
Je suis pas forcé de m'y connaître en linux pour m'être documenté un peu sur Wine

Si.

./55 > Non ? C'est dommage, parce que wine existe pour windows.

(et y a une version pour OS X, il me semble)

fp (./58) :
./55 > Non ? C'est dommage, parce que wine existe pour windows.

Je pense qu'il sous-entendait que le fonctionnement de Wine change selon l'OS.