M a écrit 2996 commentaires

Ben le francais n'est pas bien supporté :
http://www.languagetool.org/download/README.txt

LanguageTool, a language style checker for English, German, Polish,
and Dutch with initial support for Spanish, French, and Italian


Et puis "sont élue ai parti" aboutit après correction à "Son élue ait parti"... De même "Son élue est parti" est considéré valide.

Deja en 2006 [1]...
Sujet relancé en 2007 [2]

[1] http://www.disqueenfrance.com/snep/dossiers/2006_10.asp ...
[2] http://www.disqueenfrance.com/snep/dossiers/2007_01_14.asp

Mais ca s'applique aussi à Picidae et tout proxy...

Et sur swfdec, il n'ont pas l'air de vouloir l'utiliser non plus...

Toutefois, pour bénéficier de la correction orthographique, il fallait jusqu'à présent installer soi-même le dictionnaire français.
Sous debian, ca a toujours fait automatiquement...
Et même sur seamonkey...

Sur les video simple (pas de fondu à la youtube), je crois que le player proprio utilise du XV...

Je me suis amusé, sur du code C à jouer à intervertir certaines instructions commutatives dans des boucles critiques (merci gcov) pour mutualiser les read/write.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.

De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage
Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.

Et au passage c'est par exemple un choix technique de swfdec (http://swfdec.freedesktop.org/wiki/FAQ), mais gnash ne fait pas mieux...

Un java light pourrait être très intéressant.
Mais bon, faut qu'ils pensent à faire une couche multimédia performante.
Parce que j'ai regardé il y a pas longtemps et pour faire un lecteur video, il faut forcement sortir du RGB (et donc se farcir la conversion en java)...

T'as essayé les versions open source.
Parce que à se niveau elle resemble vraiement au plugin proprio...

Regardes le succès de l'IA64 ...

Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).

Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.

Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...

Sauf qu'intel avait deja fournit ses specs/drivers pour les i810.
Nvidia publiait un driver 3D libre (mais bien offusqué) pour les riva.
Matrox publiait des specs.

PS : maintenant il faut avoir des drivers correct. Vu la complexité de ces cartes, il y a du boulot.

Il pourrait peut etre essayer de travailler avec les distrib (et regarder leur buzilla).
Par exemple celui de debian est bien rempli : http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&d(...)

Le module que tu charges c'est pour des cartes satellittes, par des cartes DV...

Surtout que les personnes de chez adobe on l'air de répondre assez rapidement : http://www.adobeforums.com/webx/.3c05ae39
Reponse 1h30 apres la question un 31 décembre...

Tiens? Moi j'aurais dit Intel..
Bof, j'ai une carte intel qui marche plus depuis une update du driver sous debian sid...
Du coup c'est soit vesa (ou bidouille dans le xorg.conf).

C'est déjà assez ridicule de voir qu'une animation aussi simplissime pompe autant de CPU (cf les autres commentaires) que Flash quand il joue une vidéo sur Youtube/Dailymotion en fullscreen ou des musiques sur Deezer !
C'est déjà assez ridicule de voir qu'une vidéo (de pas tres bonne qualité) sur Youtube/Dailymotion en fullscreen ou des musiques sur Deezer pompe autant de CPU que pour lire une video HD avec mplayer (ou tout player multimedia digne de ce nom).

hm, un vrai défragmenteur pour Linux existait deja à cette époque :
http://freshmeat.net/projects/defrag

Est-ce que SDIO a des caractéristiques tellement uniques que ça justifie une n+1-ième norme ?
L'usb host est assez lourd (a la fois en taille dans le chip et a la fois au niveau soft).
Avec l'usb host il faut gérer les hubs, les périphériques de différentes vitesse. En plus l'usb host qui coordonne le tout doit constamment faire une sorte de pooling sur les périphériques. C'est soit fait en hard (mais le controlleur est cher), soit en soft (mais bonjour les perfs).

Au contraire la sd/sdio c'est tout con : c'est quatre fil de data, un de commande et un autre d'horloge.

le support de la norme Secure Digital Input Output fait son entrée au sein du code permettant de gérer les cartes mémoires MMC et SD. Cette modification autorise le branchement sur un port SD de divers gadgets: Récepteurs GPS, adaptateurs Wi-Fi ou Bluetooth ou Ethernet, Lecteurs de code-barre, Tuners FM ou TV, Appareils photos, etc.

Il faut tout de même que le contrôleur sd-card soit compatible sdio.
Il y a des différences entre le protocole sd-card et sdio. La sdio peut émettes des IT, les transferts sont de taille variable, ...

Pierre Ossman, qui est le mainteneur officiel du sous-système MMC/SD, a annoncé que trois pilotes SDIO étaient déjà inclus dans le noyau et que le travail continue pour inclure de nombreux autres pilotes. Néanmoins il tient à avertir les développeurs que son implémentation de SDIO force à écrire proprement le code des pilotes :

Le problème vient parfois du hardware (controlleur sdio ou carte sdio) qui oblige a faire certains hacks (par ce qu'il ne sont pas forcement 100% conforme à la norme).
C'est l'éternel problème on cherche à respecter à 100% la spec ou on supporte un max de hardware.
Sachant que le sdio est plutôt utilisé dans l'embarqué, je crains malheureusement des hacks pour s'adapter au contrôleur sélectionner par les acheteurs (ceux qui sont les moins cher).

De plus quand je vois que pour l'acpi on en arrive à copier le comportement windows, je sais pas si ce modèle tiendra .

PS : d'ailleurs je crois que openmoko ont abandonné l'idée d'utiliser cette stack, pour utiliser celle libéré par atheros (ou montavista).

Sinon, Java peut faire la même chose et plus mais charger une JVM en mémoire pour faire un petit graphique c'est lourd.

Par ce que tu crois que les nouveaux navigateurs ne vont pas être aussi lourd que les jvm java (il faudrait seulement charger la jvm a l'avance) ?

D'ailleurs certains pour avoir des perfs correct en java script comptent utiliser des VM (cf tamarin pour firefox)...

Et quand on parle de lourdeur, quand je vois les perfs des video en flash, ca rame a fond parce qu'ils n'utilisent pas les accélération video (XV) a cause de la transparence et autre effets. Et ben je dirais que les gens s'en foutent (sur les conseils des vendeurs ils achètent de nouveau PC).

Le support de la balise < canvas > est déjà effectif dans Safari, Opera et Firefox soient les meilleurs concurrents d'IE.
Quel pourcentage de navigateur en utilisateur ça représente (pour FF je suppose que c'est que les dernière versions) ?
Quel sont les outils pour générer simplement du code pour les canvas ?
Si tu veux faire des effets avancé (transparence) comme en flash, a tu déjà des libs toutes prêtes ?

Donc en gros pour lire une vidéo Flash, il faut passer par un format d'animation _fermé_
Les nouvelle version de flash supporteront mp4/h264/aac : http://wiki.multimedia.cx/index.php?title=Adobe_Flash_Player

Moi je parle de VC1 car c'est la meme chose de WMV9 (aussi appelé WMV3),
Pas tout a fait WMV9/WMV3 contient certaines features qui ne sont pas présente dans la spec VC1. C'est le cas des "J-frames" par exemple.

(Et Adobe doit faire un peu la gueule, même si Flash a de beaux jours devant lui.)
Oui ...
il faut attendre que le truc soit implementé dans les navigateurs, mais aussi qu'il y ai des editeurs corrects.
De plus pour le son/video il faut jouer avec d'autres bout de HTML 5.
Bref ca sera pas utilisable au moins avant 5 ans, alors que le flash tourne a plein regime actuelement.

C'est un peu l'équivalent de l'API Java2D.
Qu'est ce qui garanti que ce truc n'aura pas autant de succès que les applet java qui permette de faire la même chose...

Au fait le svg il devient quoi dans tout ça.

PS : html ou pdf : qui sera le truc qui sera le plus lourd ?

Matroska est simple, clair, facile à décoder, sans bidouilles (ou presque).
Bof dans matroska il y a des cas particulier pour chaque type de codec...
Par exemple les video real ne sont pas gerer de la même maniere qu'une video mpeg4.