Bonsoir,

Je n'ose pas fragmenter votre message bien que la première partie a déjà des réponse dans un autre sujet.
Je vous engage à modifier votre message pour se concentrer sur le la gestion du cache :-)

Merci ;-)

Lorsque l'on visualise une page de miniatures, il n'y a pas de pré-chargement et je ne pense pas qu'il soit opportun d'ajouter cette fonction. Les miniatures sont justement là pour éviter de charger trop de photos et ainsi, générer des pages légères.

Lorsque l'on visualise par contre des images en taille standard, là oui un pré-chargement serait déjà plus approprié.

Sur le diaporama il me semble qu'une telle fonction est implémentée... (à confirmer).

@Gotcha :
en effet, je confirme que le diaporama intègre bien un preload de l'image suivante !
Et effectivement, c'est du bonheur. Il ne manquerait plus qu'a lier a la fonction de resize dynamique dont je parlais, pour preloader uniquement l'image "utile", et ca serait parfait !

Et en fait, il fonctionne egalement sur la navigation entre les pages !
mais il ne marche pas bien chez moi, c'est pour ça que je ne l'avais pas remarqué  .. :( si je laisse l'image suivante se precharger, lorsque je vais sur la page suivante,une fois sur 2 l'image ne s'affiche pas.
Si je rafraichis la page, elle se recharge et s'affiche correctement

En outre, la requete semble etre faite dans le corps de la page au lieu d'etre en XHR, ce qui fait qu'elle ralentit la requete principale.
Exemple de timeline sur mon chrome ci joint. Ca laisse une fausse impression de lenteur, c'est dommage.

Pour la page des miniatures, je ne parlais que de la 1ere photo (la plus "probable" a étre cliquée en premier), et c'est un preload ajax, XHR , donc la page reste ultra légère : ce n'est qu'une fois qu'elle est entièrement chargée qu'on peut anticiper sur le chargement de la prochaine photo.

Sinon Je viens de comprendre sinon comment PicasaWeb faisait pour aller aussi vite .. il gere toute la navigation entre les photos sur une seule page.
Pur ajax et manipulation du dom. Et du coup, quand il a le temps, il télécharge autant de photos qu'il peut (jusqu'a 10) en prenant comme parametre la fenetre courante, et en redimmensionnant les images de manière similaire au code php que j'ai cité en exemple pour imagick.

En combinant toutes ces techniques, (ainsi qu'eventuellement un connecteur CDN sur le S3 d'amazon :P ) , on obtiendrait un outil d'une performance inégalée, aussi rapide qu'un navigateur local.

ddtddt : je n'ai pas compris ce qui changera a la prochaine version ?

Dernière modification par arno (2011-01-15 22:11:40)

Bien reçu,
le projet est en effet enthousiasmant et plein de potentiel.

J'ai pas mal de background en projet web, mais peu de compétences de developpement en php :( je vais en tout cas regarder tout ça de près et reflechir de quelle manière je peux contribuer de manière efficace.

- Arno

arno a écrit:

...
Et en fait, il fonctionne egalement sur la navigation entre les pages !
mais il ne marche pas bien chez moi, c'est pour ça que je ne l'avais pas remarqué  .. :( si je laisse l'image suivante se precharger, lorsque je vais sur la page suivante,une fois sur 2 l'image ne s'affiche pas.
Si je rafraichis la page, elle se recharge et s'affiche correctement
...

Bonjour.
Juste un petit rappel:
  Au sujet du preload avec chrome:
Lien : http://fr.piwigo.org/forum/viewtopic.ph … 98#p158998

   
A+

Hello,

ok, je reprend la discussion ici, commencée sur
http://fr.piwigo.org/forum/viewtopic.ph … 8#p158998,
pour l'élargir au probleme du prefetch /preload de façon générale et de sa gestion sur piwigo

Je fais une synthese, qui reprend aussi les points évoqués aussi ci desssou

Petite clarification pour eviter de mélanger les problemes :
1) le DNS-prefetch de chrome n'a rien à voir avec le prechargement des éléments :
Il s'agit de résourdre à l'avance les noms de domaine des liens qui se trouvent sur une page, pour eviter les temps de résolution.
Mais en aucun cas de télécharger les éléments contenus sur cette page !
Plus d'informations ici : http://dev.chromium.org/developers/desi … refetching

2) la balise rel="preftech" est une balise du draft HTML5. Elle est exploitée en anticipation depuis quelques mois/années par firefox , et effectivement depuis peu par chrome sur ceux qui ont activés les versions de developpement depuis novembre 2010.
cf http://trac.webkit.org/changeset/69420
Pour info, sur la discussion de http://www.google.com/support/forum/p/c … &hl=fr , les "spécialistes google" n'y connaissent vraiment rien, je conseille vivement pour toutes les questions pointues concernant chrome d'aller sur http://dev.chromium.org/Home

Pour les autres navigateurs/versions , elle n'est pas prise en compte, et est simplement ignorée par les navigateurs qui ne la supportent pas.

3) Le preftech agressif des ressources sans utilisation de balise est un code réalisé coté client, site par site, et ne dépend pas du browser.
- Il est par exemple utilisé activement sur google.com
- Fasterfox est un plugin firefox qui automatise le prefetch sur les pages qu'il parcoure.
- la gallerie picasa web est un exemple de prefetch (ou plutot de preload) des ressources, en anticipation de la navigation. (téléchargement des 10 images suivantes, au format de la fenetre actuel).
Pour l'implanter, voici un exemple d'utilisation
http://www.positon.org/post/Pr%C3%A9cha … javascript

4) Sous chrome, pour piwigo, on voit que chome prefteche l'image suivante , de la meme manière que sous firefox.
Le probleme est que sous chrome, c'est assez mal implanté, dans le sens ou ca n'attend pas que la page soit chargée (donc ralentit le téléchargement de la photo en cours), et fait planter regulierement l'affichage de la photo suivante sous chrome.
Ci joint la timeline, sous  chrome 8.0.552.237
DSC03414 est la photo précédente.
DSC03414 est la photo courante
DSC03422 est la photo suivante.
On voit bien le téléchargement de DSC03422 , qui commence avant meme le téléchargement de DSC03414

Le champ "X-purpose: preftech" est ajouté dans la requete.

Je voulais reverifier sous firefox, mais là ca ne marche plus ..
http://piwigo.cumulodata.com/picture.php?/15/category/3
pour une raison que j'ignore. (Fx3.6)

Conclusion:

IMHO, il est indispensable de désactiver cette balise (rel=prefetch) instable et pas encore officielle; et de développer un mécanisme (cf 3) connu, maitrisé, compatible sur tous les navigateurs (à part eventuellement IE6 ..), et qui permettra un réel confort de navigation.
Quel bonheur de ne pas attendre le chargement de la photo suivante !
Et qu'il parait stupide" à juste titre pour l'utilisateur que le PC ne fasse rien lorsqu'il a fini de charger la photo actuelle, alors qu'il y a une probabilité importante qu'on aie besoin de charger la photo suivante dans les secondes qui suivent !
Avec une proba non nulle qu'on en aie pas besoin, c'est tout le sens des strategies de prefetch, qui peuvent etre ajustées plus finement quand on en maitrise le mécanisme, ce qui plaide d'autant plus pour un controle manuel.
Exemple: ne pas preftecher si on detecte un contexte ou la data peut etre payante, comme un navigateur mobile.

Pour élargir le débat, 2 pistes :
- Naviguer sur une seule page. Ce qui signifie que non seulement on précharge les images suivantes, mais qu'on ne recharge pas les éléments qui ne changent pas.
=> navigation instantanée, locale.
Cf: http://picasaweb.google.com/Globetrotte … 8294341858
cliquez sur "suivant"
Les 10 photos suivantes sont préchargées lorsque le navigateur a fini avec la photo actuelle.
Et la navigation se fait grâce aux anchors, pour continuer a avoir des URLs cohérentes.

Ca peut paraitre ambitieux, mais en fait c'est plutot assez simple , comparé par exemple a ce que fait dans la meme veine rvelices sur la page des thumbnails
http://piwigo.org/forum/viewtopic.php?id=16889
voir la demo ici, pour ceux qui n'ont pas vu. http://www.modusoptimus.com/pwg/index/tags/nightscape

- Si on associe ce prefetch  a un téléchargement uniquement du format d'image qui correspond à l'ecran, on a enfin une navigation fluide, instantanée, quel que soit le format des photos d'origine. cf disucssion sur http://fr.piwigo.org/forum/viewtopic.ph … 1&p=16

Voilà, désolé pour ce billet un peu long mais c'est un sujet qui me tient a coeur pour faire de piwigo un vrai outil 'professionel'

- Arno

Merci de remettre cette discussion au "goût du jour". Je pense que la désactivation du preload pour Chrome (fait pour Chrome 9 il me semble) n'est plus pertinente avec Chrome 12 et 13 qui sont les seuls que je vois dans les statistiques de visites de Piwigo.org/Piwigo.com.

Est-ce que quelqu'un qui constatait ce bug peut le reproduire avec Chrome 12 ou 13 ?

Dans picture.php, ligne 667, il faut remplacer :

    and strpos($_SERVER['HTTP_USER_AGENT'], 'Chrome/') === false)

par

    and strpos($_SERVER['HTTP_USER_AGENT'], 'Chrometralala/') === false)