Geckozone

Le support de l'accélération hardware par des cartes supportant Direct3D version 9 vient d'arriver: Bug 546515 - Direct3D 9 Layers Backend

Pour Windows 2000 et ultérieur, si votre carte est adéquate.

A voir la réaction des testeurs fous ces prochaines heures.

En vrac:

• Un billet résumant l'accélération matérielle dans Firefox: http://blog.mozilla.com/joe/2010/05/25/ ... g-firefox/
• Tracemonkey a été amélioré dans la nouvelle nocturne: j'ai un gain de 8% sur SS aujourd'hui. Sur mon Mac, le Trunk donne de meilleur résultat que Safari 4.0.3 et se rapproche bien de Safari 4.0.5. Encore pas mal de retard sur les prealpha de Webkit ou les versions récentes d'Opera ou Chrome. Mais déjà 20% de mieux que Firefox 3.6.
• Les proxies harmony (ES6?) sont arrivés. J'avoue n'avoir (encore) aucune idée de ce que c'est...
• Robert O'Callahan travaille sur le scrolling (dans le cadre des Retained Layers). Cela semble très performant en particulier sur les pages "difficiles".
• Une version expérimentale de Sqlite diminuant le nombre de fsync (un vieux problème d'utilisation disque surtout sous Linux) pourrait arriver bientôt: http://www.sqlite.org/draft/wal.html

Tu n'as que 20% de mieux sur SS entre 3.6 et trunk sous mac? J'ai plus de 50% sous Linux.

pascal a écrit :Tu n'as que 20% de mieux sur SS entre 3.6 et trunk sous mac? J'ai plus de 50% sous Linux.

J'ai 1030 ms pour Fx 3.6 et 820 ms pour le Trunk d'aujourd'hui (à peu près). (Evidemment le nombre dépend de la machine). [Safari 4.0.3: 865 ms, Safari 4.0.5 (l'actuel): 740 ms]
Sauf erreur il y a eu un gain supplémentaire sous Linux (Option "fomit-pointer"); à vérifier.

Par contre sur le test V8, j'ai 110% de gain (310 -> 630), mais là les autres sont encore loin devant.

[Edit:] Pour comparaison Chrome 5 (meilleur qu'Opera 10.5x ou les nocturnes de Webkit) me donne 475 ms sous SS. Et si je prends la meilleure performance de chaque test, j'obtiens 370 ms. Et je pense qu'on peut encore aller plus bas (puisque tous ces engines n'utilisent qu'un seul cœur et que j'en ai deux).

Moi sous Linux j'ai 1198 pour Firefox 3.6 et 786 pour le trunk d'aujourd'hui, 35% de moins. Mais bon, les perfs sous Linux partaient de plus loin je pense

sur ma machine sous W7 je passe de 1435 (FFX3.6.3) à 1050ms avec la derniere build, soit -27%

Zefling a écrit :
En tout cas ce que je note, ce qui est toujours en expérimentale niveau CSS :

• E::selection

Pour info, E::selection a été retiré de CSS3 Selectors en 2009 (malgré que cela y était en 2001). Il y a eu pas mal de discussion à son propos sur la mailing-list du groupe de travail le mois dernier, mais le problème est que c'est sous-spécifié pour l'instant (et vu les différences d'implémentation entre les navigateurs, quasi-inutilisable sauf pour des trucs triviaux). Ce ne sera donc selon toutes vraisemblance pas dans CSS 3. Mais probablement dans "CSS3.next Selectors", avec deux-trois trucs qui attendent comme :any() .

Je ne savait pas, j''espère que Mozilla va pas le virer de Gecko, j'aurais une couleurs toute pourrie quand je sélectionnerais des trucs sur mon site.

S'ils pourraient faire aussi un truc comme :parent, l'inverse de + et ~, ça serait pas mal, puis aussi le no-change que j'avais évoqué.

Zefling a écrit :Je ne savait pas, j''espère que Mozilla va pas le virer de Gecko, j'aurais une couleurs toute pourrie quand je sélectionnerais des trucs sur mon site.

Non, non ça va y rester. Le but est de standardiser le truc même si ce sera dans l'itération suivante. Le fait qu'il ait été en CR a permis à certains de tomber le préfixe, ce qui pose problème, puisque la définition du sélecteur est imprécise.

Pas eu le temps de faire des messages individuels, mais il y a eu ces derniers jours quelques petites nouveautés notables:

• Un nouveau menu contextuel dans le Gestionnaire des mots-de-passe: Copy Password (Le bug);
• Amélioration de la copie dans le presse-papier: ce qui est caché par visibility:hidden, visibility:collapse ou display:none n'y est plus copié (Le bug) [Le bug avait été signalé en 2000];
• Un petit détail visuel corrigé dans les formulaires sous Windows (Le bug). Avec une image pour montrer le problème avant:
  C'est le genre de détail que j'aime voir être corrigé.
• Encore une amélioration de l'about:memory (Le bug);
• 3-4% d'amélioration au test Sunspider (nettement meilleur que Safari 4.0.3 désormais et cela se rapproche de Safari 4.0.5);
• Arrivée des Proxies en JS (dans le cadre du projet Harmony, le futur ES6);
• Les barres d'outils (personnelles) cachées apparaissent en mode configuration (pour pouvoir récupérer des éléments qui y seraient) (Le bug).

Sinon, Robert O'Callahan travaille sur les Retained Layers (et le scrolling), les premiers checkin commencent à avoir lieu (des détails pour l'instant). Un étudiant, dans le cadre du Google Summer of Code, se lance sur l'implémentation de TLS 1.1 et TLS 1.2. Il y a également de l'activité sur les HTML5 Forms (début des réflexions sur les nouveaux widgets graphiques) mais également un peu d'activité pour rendre les alertes modales aux onglets (et non plus aux fenêtres).

Concernant les mot de passes, dommage qu'ils ne se préoccupent pas plus de s'intégrer au trousseau d'accès du système, mais il y a déjà tellement de trucs à régler.

Thomas a écrit :Concernant les mot de passes, dommage qu'ils ne se préoccupent pas plus de s'intégrer au trousseau d'accès du système, mais il y a déjà tellement de trucs à régler.

Il y a une extension pour Gnome : Gnome-keyring password integration. Je n'ai pas connaissance de tels projets pour d'autres systèmes.

À propos de -moz-calc(), je cherche un exemple simple à comprendre mettant en valeur son intérêt. Typiquement, pour éviter l'utilisation de divs inutiles.

Si vous avez des suggestions, je suis preneur (c'est pour un article sur hacks.mozilla.org).

Ha! Séquences de variations idéographiques, késako?

C'est pas compliqué, mais il faut quelques explications. Les pages web contiennent du texte, c'est-à-dire une suite de signes (Pour les langues occidentales, le plus souvent des lettres, des symboles et des chiffres; mais pour d'autres langues il y a des symboles syllabiques ou des idéogrammes, etc). Ces signes sont codés (de plus en plus souvent en Unicode, et c'est le seul à supporter ce qui nous intéresse) et l'un des rôles d'un navigateur est d'afficher ces codes correctement, en les remplaçants par le glyphe approprié.

Le glyphe est la représentation graphique du signe (ou de la lettre si vous préférez même si tout signe n'en est pas forcément une). Là où cela se complique c'est qu'un même signe peut être représenté par plusieurs glyphes (et vice-versa, dans le cas des homographes, mais cela ne nous intéresse pas ici). Ainsi le signe LETTRE_LATINE_A_MINUSCULE peut être représenté par de nombreux glyphes: aaaaaaa sans oublier les différentes polices (Helvetica, Arial, serif, sans-serif, etc, etc. La liste des glyphes possibles pour chaque signe est quasi infinie.

Le navigateur doit donc choisir le bon glyphe pour cela, il procède ainsi:

1) Chaque police est une collection de glyphes. Il choisit la police adaptée en fonction du style (nom et type de police, graisse, italique, couleur)
2) Pour les différentes glyphes de la même lettre mais dont le choix est dicté par les règles orthographique (utilisation d'une majuscule pour la capitale d'une phrase ou d'un nom propre en français par exemple), il se base sur les indications de l'auteur: des signes différents pour des glyphes différents.
3) Dans certaines langues (l'exemple le plus connu c'est l'arabe), le même signe (lettre) peut devoir être rendu par 4 glyphes différents en fonction de la position: le glyphe pour les usages isolés, celui pour son usage en tête de mot, en milieu de mot ou en fin de mot. Là le logiciel de composition typographique choisit comme un grand le glyphe adéquat. On peut souvent utiliser un système similaire pour les ligatures (qui lient plusieurs signes) ou les digrammes (æ, Æ, ligature latine; œ, Œ, ligature français ou d'autres balkaniques plus compliquées puisque le signe est un digramme en minuscule, mais seul le premier composant prend la majuscule lorsqu'il est utilisé en capitale)
4) Enfin, et c'est ce cas qui nous intéresse, dans certaines langues utilisant des idéogrammes (chinois, japonais ou coréens par exemple), certains idéogrammes ont été simplifiés au cours du temps (même et surtout récemment, au XXe siècle). Pour le même signe, il y a donc plusieurs idéogrammes possibles (au Japon tous les journaux n'ont pas adoptés la dernière réforme par exemple). Ainsi Unicode 5.1 a défini les séquences de variations idéographiques (IDS): un code spécifique est ajouté au code Unicode de l'idéogramme indiquant le glyphe souhaité et, s'il est disponible, c'est celui-là qui est utilisé, sinon c'est le glyphe de base qui est rendu. (Il y a d'autres usages, les nombres japonais ou les noms de famille orientaux).

Les IVS sont apparus dans Unicode 5.1 vers mi-2007 et sont également utilisés, outre les trois langues CJK, par le mongol. Pour pouvoir les utiliser il faut avoir des polices adéquates (elles existent et viennent avec les produits Adobe par exemple), un OS qui le supporte (Windows 7 avec Uniscribe le supporte, de même que OS X 10.6 (mais pas antérieur); DirectWrite devrait pouvoir permettre le support des IVS sous Vista; pour Linux, je ne sais pas) et un logiciel adapté (Opera, Flash et les autres produits Adobe, les applications livrées par défaut avec les OS le supportant comme TextEdit sous Mac).

Voilà,

Firefox supporte sous Windows 7 les IVS depuis cette nuit. Il reste quelque bug sous Mac OS X 10.6. Quant aux autres, il y a un bug ouvert pour l'étude, mais cela n'est pas encore fait.

Quelques infos:

• Bug 552460 - implement Ideographic Variation Sequences support
• http://en.wikipedia.org/wiki/Unicode_co ... _selectors
• http://blogs.adobe.com/typblography/200 ... aphic.html
• http://m10lmac.blogspot.com/2010/02/os- ... ation.html
• http://blogs.adobe.com/CCJKType/2010/02 ... tatus.html
• http://www.unicode.org/ivd/

Voilà, pas forcément très utile pour nous en Occident, mais nécessaire à maintenir Firefox à jour avec les technologies de typographie et utilisée en Extrême-Orient.

paul.rouget a écrit :À propos de -moz-calc(), je cherche un exemple simple à comprendre mettant en valeur son intérêt. Typiquement, pour éviter l'utilisation de divs inutiles.

Si vous avez des suggestions, je suis preneur (c'est pour un article sur hacks.mozilla.org).

Je pense qu'il vaut mieux poser la question sur les forums d'alsacréations, il y a plus d'intégrateurs.

La seule réponse qui me vient à l'esprit est annihilée par box-flex => placer deux divs verticalement (typiquement un header de hauteur fixe et un conteneur qui prend toute la place qu'elle que soit la taille du contenu). Chacun a un width:100%, le header a une hauteur de 50px et si on met height: 100% au conteneur, il sort de l'écran. -moz-calc(100%-50px) résout la soucis, mais je préfère utiliser box-flex au final :p