Geckozone

caméléon a écrit :Il faudrait surtout que les fabricants d'appareil photo numériques se décident à passer au jpeg du 21 siècle…

Encore faut-il qu'ils y trouvent un avantage. Le poids, ils s'en moquent totalement et on voit mal pourquoi ils s'en préoccuperaient vu la baisse constante du prix au Mo des cartes mémoires et des disques durs. Le poids des images est important pour le web, pas pour les APN.

La qualité peut les préoccuper plus (quoique…).
Pour le jpeg2000, il ne semble y avoir aucun de différence avec le jpeg. Si c'est le cas, le format n'a aucun intérêt pour eux, surtout avec une licence pas claire.
Le jpeg-XR embarque des trucs totalement inutiles en photo (multi "pages", canal alpha, CMJN ch… à traiter et qui sera toujours en dessous du RAW) et sa licence est encore moins claire que celle du jpeg2000.
WebP. Là, on peut avoir quelques inquiétudes sur la qualité : "without perceptibly compromising visual quality" (ici). Ce n'est pas parce que la dégradation est imperceptible sur une petite image sur une page web qu'elle n'est pas rédhibitoire pour un usage photographique. En photo, l'usage le plus probable sera certainement sur les téléphones portables.

De plus, tous les fabricants dominent parfaitement la chaine de traitement pour le jpeg et n'ont probablement pas envie d'investir en R&D s'il n'y a pas un réel avantage pour eux (et, accessoirement, pour leur clients). Il faut voir aussi qu'un APN n'est pas un PC et que le hardware et software embarqué doit pouvoir traiter la photo le plus vite possible sans faire exploser les coûts de fabrication et de développement logiciel.

Bon, suis "un peu" HS, là.

Deux articles sur le WebP :
http://www.pcinpact.com/actu/news/59665 ... s-jpeg.htm
http://x264dev.multimedia.cx/?p=541

caméléon a écrit :Combien de temps avant qu'un bug soit ouvert sur Bugzilla ?

[edit]: trop tard (depuis quelques heures)...
Bug 600919 - Implement WebP image support

Et maintenant c'est le patch. Mais il ne faudra pas s'attendre à le voir dans Firefox 4.

Document.height & document.width ont échappés à la disparition dans Gecko 2, mais ces trucs propriétaires ne devraient pas survivre dans Gecko 2.1..

Le bug à suivre: #585877[Core:DOM]-remove document.height / document.width [All]

C'est vieux, mais on a ceux choses prévue pour Firefox 4.Next (j'en ai déjà parlé, mais pas sur ce topic) :

-L'interface unifiée (étendue au gestionnaire de téléchargements et peut-être/sûrement aux bookmarks/à l'historique
-Le nouveau gestionnaire de téléchargement

Salut,

Zefling a écrit :

caméléon a écrit :Combien de temps avant qu'un bug soit ouvert sur Bugzilla ?

[edit]: trop tard (depuis quelques heures)...
Bug 600919 - Implement WebP image support

Et maintenant c'est le patch. Mais il ne faudra pas s'attendre à le voir dans Firefox 4.

En attendant, et au cas où plein d'images WebP se mettent à fleurir le Web, il sera possible d'utiliser un userjs (compatible avec Firefox 4, probablement via l'extension GreaseMonkey) qui se contente profiter du décodeur WebM intégré pour afficher l'image convertie en vidéo d'une seule trame...
http://extendopera.org/userjs/content/webp-support

@+
--
Pierre

J'attends déjà d'avoir des outils de conversions pour faire les images, parce que pour l'instant, la majorité des images que je mets sur le net, c'est PHP/GD qui s'en occupe.
Puis sans le profil de transparence, ça m'intéresse pas des masses.

Il me semble que j'avais déjà posé la question, mais je ne me souviens plus de la réponse et je ne retrouve plus le fil correspondant : TaskFox a-t-il été abandonné ?

Morgoth a écrit :Il me semble que j'avais déjà posé la question, mais je ne me souviens plus de la réponse et je ne retrouve plus le fil correspondant : TaskFox a-t-il été abandonné ?

A ma connaissance, oui.

Cela fait longtemps qu'il était en sursis, mais il va bientôt disparaître!

Le Profile Manager va être supprimé dans Fx.next; Fx supportera toujours les profils multiples, mais il n'y aura plus d'interface par défaut. A la place, Mozilla développe une application indépendante pour gérer ce point-là. Ils recherchent d'ailleurs un look pour les icônes.

Plus de détail: http://jagriffin.wordpress.com/2010/10/ ... requested/

Et le bug (mais n'y commentez pas, ce n'est pas le lieu!): #214675 [Toolkit:Startup and Profile System]-Remove Profile Manager UI

Les deux propriétés text-decoration-style et text-decoration-color sont prêtes à passer en "révision de code" avec pour but d'être disponible dans Fx.next. Comme la spec est encore en Working Draft, ils seront précédés de -moz et ne pourront pas (encore) être utilisé dans la propriété abrégée text-decoration.

#59109 [Core:Style System (CSS)]-implement CSS3 text module's text-decoration-style and text-decoration-color

À suivre!

La décision est tombée: les HTML5 Server-sent DOM Events, bien que prêt, ne seront mis dans le Trunk qu'après la création de la branche Firefox 4.

Ils seront donc dans Firefox.next.

C'était au fin fond d'un bug, mais Robert O'Callahan a (un temps soit peu) décrit les prochains buts pour l'évolution de la plateforme (post Fx-4), surtout côté SVG.

Donc voici ce que l'on peut s'attendre (non exhaustif) pour Firefox.next (Gecko 2.1):

• Retained Path API pour Cairo (bug 555877) accélération du SVG sous Direct2D et un peu pour la plateforme
• Refactorisation du code SVG pour utiliser les display-list
• Accélération des calques SVG
• Invalidation par les display-list (pour SVG, dépend du bug générique)
• Accélération de SVG et <canvas> en refactorisant Cairo pour être un wrapper plus léger autour de Quartz, D2D: c'est la cairo_backend-t branche où travaille Chris Wilson
• Amélioration du backend cairo-gl pour accélérer <canvas> pour Mac et Linux

Je vois que ça parle de Quartz et D2D, y'a rien de prévu pour Linux?

Uther a écrit :Je vois que ça parle de Quartz et D2D, y'a rien de prévu pour Linux?

Ben XRender était déjà dans Fx 3.6 (mais cairo-backend-t l'englobera aussi)... Et OpenGL fonctionne avec Linux dans Fx 4...