DEV Community: Quentin Philippot

Optimisation des images pour des performances web : techniques et conseils

Quentin Philippot — Sat, 05 Aug 2023 09:10:55 +0000

L'optimisation des images est un aspect crucial pour améliorer les performances d'un site web.

Que ce soit dans le cadre d'une démarche Green IT, pour améliorer l'expérience de vos utilisateurs, ou simplement optimiser votre référencement en soignant vos Core Web Vitals, la gestion des images a un impact direct sur la qualité de votre site.

Dans cet article, nous allons explorer différentes techniques d'optimisation des images pour garantir une expérience utilisateur fluide et agréable.

Attention : cet article n'a pas pour vocation d'être un guide exhaustif.

Je me concentrerai sur les optimisations les plus impactantes rencontrées au cours de mes expériences professionnelles. 😉

Dimensionner et compresser ses images

La compression des images est l'une des premières étapes de l'optimisation. Elle consiste à réduire la taille des fichiers sans compromettre la qualité visuelle.

Il existe des outils de compression en ligne, tels que TinyPNG et JPEGmini, qui permettent de réduire considérablement la taille des images sans perte visible de qualité. En compressant vos images, vous réduisez le temps de chargement de vos pages et économisez de la bande passante pour vos utilisateurs.

Privilégier les images vectorielles

Il existe deux grosses familles d'images.

Matricielle : l'image est composée d'une grille de pixel, et des artefacts peuvent apparaître lorsqu'on modifie le facteur de zoom ou que l'on compresse l'image. C'est à cette catégorie qu'appartiennent nos bons vieux png et jpg.
Vectorielle : l'image est définie par un ensemble de directives indiquant à votre navigateur comment la "dessiner". Généralement plus légères, elles présentent l'avantage de pouvoir être redimensionnées sans perte de qualité. Le plus souvent, on utilise du svg.

Pour des formes simples avec assez peu de texture, le format SVG est généralement la meilleure solution.

Toutefois, voici quelques éléments de vigilance :

Sur de toutes petites images (type icône), les images matricielles peuvent parfois se révéler plus légères que les vectorielles.
Les svg contiennent souvent des commentaires qui augmentent inutilement le poids des fichiers, pensez à les retirer et à minifier vos fichiers pour de meilleures performances !
Certains logiciels proposent d'exporter des images matricielles complexes au format svg : la transformation n'apportera souvent aucun gain de performance.

Images adaptatives et `srcset`

Les appareils et écrans varient en termes de résolution, de taille et de densité de pixels. Par exemple, la zone
d'affichage pour une image sur un écran de bureau peut être de 512x512 pixels, tandis que sur un téléphone, elle sera
plus petite, disons 256x256 pixels.

Cette disparité justifie l'utilisation du srcset. Il permet de proposer différentes versions d'une même image,
adaptées à ces variations, afin d'optimiser l'affichage en fonction de chaque appareil.

Si vous souhaitez en savoir plus sur l'intérêt de mettre en place des images adaptatives via l'usage de srcset, vous pouvez consulter cet article explicatif.

Exemple de mise en place :

<img
        src="chemin/vers/mon/image-320w.jpg"
        srcset="
            chemin/vers/mon/image-320w.jpg 320w,
            chemin/vers/mon/image-640w.jpg 640w,
            chemin/vers/mon/image-1280w.jpg 1280w"
        sizes="
            (max-width: 320px) 280px,
            (max-width: 640px) 600px,
            1200px"
        alt="Ma superbe image"
>

Dans cette situation :

src spécifie le chemin vers l'image de référence pour les navigateurs qui ne prennent pas en charge l'attribut "srcset".
srcset contient une liste de chemins d'images accompagnés de leur largeur en pixels (w). En fonction de la résolution et de la largeur de l'écran, le navigateur choisira automatiquement l'image la plus optimisée. Si srcset n'est pas supporté par le navigateur 🦖, l'image affichée correspondra à celle du src.
sizes détermine les dimensions souhaitées pour notre image en fonction de la largeur d'écran.

L'implémentation de cette solution implique que chaque image soit systématiquement générée en plusieurs tailles et résolutions en amont, ainsi que l'écriture
des règles de srcset sur chaque élément <img/>.

Formats Next-Gen

Tous les formats d'images ne se valent pas. En fonction du contexte, beaucoup de designeurs / dev semblent avoir
développé l'heuristique suivante concernant le choix des formats :

PNG pour de la transparence
JPEG pour des images sans transparence
SVG pour des formes simples
GIF pour des images animées
etc

Eh bien, oubliez-tout, on peut faire mieux ! 😱

De nouveaux formats d'images existent permettant de répondre à ces critères avec de bien meilleurs taux de
compressions !

C'est le cas notamment des formats WebP ou AVIF.

L'ennui, c'est que, comme souvent sur le web, ces technologies ne sont pas supportées par tous les navigateurs. Il est
donc risqué de proposer ces seuls formats d'images.

Par chance, à chaque demande de téléchargement d'image, le navigateur envoi un header Accept dans la requête indiquant
la liste des formats d'images supportés par
celui-ci (doc).

En se basant sur cette valeur, on peut alors configurer son serveur pour renvoyer le meilleur format d'image disponible.

From scratch, l'implémentation de cette solution s'avère extrêmement contraignante : il faut générer chaque
format d'images et effectuer du développement supplémentaire côté serveur pour rendre ses images 🤯

Lazy-Loading

Charger toutes ses images d'une traite alors qu'elles ne seront pas toutes visibles : il s'agit d'une erreur courante qui ralentit inutilement le chargement de votre page.

Pour éviter de charger toutes les ressources au lancement de la page, on peut avoir recours à des techniques de lazy-loading.

Notez que le terme "lazy-loading" est un terme assez généraliste désignant un ensemble de techniques permettant le chargement différé des ressources (images, script, style, etc).

Avec ce type d'approche, vos gains de performance dépendront de votre réponse à la question : "Quand la ressource doit-elle être chargée ?"

Encore une fois, il existe une myriade de solutions possibles et nous en aborderons qu'un minuscule échantillon ! 😄

La balise img

Pour "organiser" le chargement des images, la balise HTML <img> dispose d'un attribut loading permettant de définir
une stratégie de chargement.

Les valeurs possibles sont :

eager : on demande au navigateur de télécharger l'image le plus tôt possible, qu'elle soit visible ou non.
lazy : on indique au navigateur d'attendre que l'image soit "proche" du viewport pour commencer le téléchargement de l'image.

Note :

J'insiste sur le fait qu'on ne donne que des "recommandations" au navigateur, et que la processus de chargement des images reste au final à sa discrétion et peut varier selon les navigateurs ou leurs versions.
Pour que ces méthodes fonctionnent, il faut que JS soit autorisé dans votre navigateur.

Pour en savoir plus : https://web.dev/browser-level-image-lazy-loading/

Intersection Observer

Si vous souhaitez avoir un meilleur contrôle sur votre stratégie de chargement des images, il est possible d'utiliser l'
API Intersection Observer.

Cette dernière permet de définir une fonction de callback à invoquer lorsqu'un élément observé entre en intersection
avec le viewport.

Le sujet mérite un tutoriel à lui seul, et ça tombe bien : il y en existe beaucoup !

Pour en savoir plus : https://grafikart.fr/tutoriels/intersection-observer-804

Utiliser une librairie

Si les deux premières méthodes ne vous conviennent pas, sachez qu'il existe des dizaines de librairies JS permettant de
différer le chargement de vos images.

Ces librairies peuvent offrir des services supplémentaires comme le chargement progressif (téléchargement de différents
niveaux de résolution, etc).

Le gros désavantage de ces solutions, c'est que selon les libs utilisées, votre stratégie de lazy-load peut ne pas être
comprise par les crawlers qui dégraderont votre index de performance en conséquence.

Soyez-donc vigilant sur ce point si le référencement est un aspect important sur votre projet.

Gestion du cache navigateur :

L'image la moins lourde, c'est celle que l'on ne télécharge pas ! 🧙 ️

Pour améliorer encore davantage les performances, vous pouvez configurer le cache navigateur pour stocker localement les images sur l'ordinateur de l'utilisateur.

Cela permet de réduire les requêtes vers le serveur pour les images déjà chargées, accélérant ainsi le chargement des pages ultérieures.

Grâce au header de réponse Cache-Control, vous pouvez contrôler la durée de mise en cache des images et améliorer l'efficacité du cache navigateur.

La difficulté avec ce genre de technique réside dans la mise à jour des images.

En effet, l'image étant conservée dans par le navigateur, purger le cache associé sera plus difficile.

Si vous êtes sûr de ne jamais mettre vos images à jour, alors vous pouvez partir facilement sur un Cache-Control: max-age=31536000 (1 an).
Dans le cas contraire, suffixer vos images par un numéro de version / hash allié à un Cache-Control long, reste encore la méthode la plus simple (à mon sens) pour garantir une bonne mise en cache côté browser.

S'il ne vous est pas possible de mettre en place l'une de ces deux solutions, sachez qu'il est possible de construire une stratégie de mise en cache beaucoup plus complexe. Pour en apprendre davantage, je vous recommande cet article.

Conclusion

L'optimisation des images est un élément essentiel de la performance web. En compressant les images, en utilisant des formats modernes, en adoptant des images adaptatives avec srcset, en mettant en place le chargement paresseux et en gérant le cache navigateur, vous pouvez considérablement améliorer les temps de chargement de vos pages et offrir une expérience utilisateur optimale. Prenez le temps de mettre en œuvre ces techniques d'optimisation, et votre site web sera plus rapide, plus efficace et plus agréable pour vos utilisateurs.

Illustation de couverture par : free-vectors.net

Créer des modales avec React

Quentin Philippot — Sat, 10 Jun 2023 09:05:04 +0000

Après avoir exploré les différences entre une modale et une boîte de dialogue dans notre précédent article, il est temps de plonger dans la pratique. 🐱‍👤

Implémentation d'une modale en React

Note : cette section utilise des iframe vers d'autres pages d'exemples disponibles vers mon blog. Celles-ci étant bloquées sur dev.to, il est possible de continuer la lecture de l'article sur mon blog.

Exemple de la modale que nous allons développer dans cet article :

Code de la modale, celui-ci sera détaillé par la suite :

//  Modal.tsx
function Modal({children, isOpen, handleClose}) {
    // 👇 L'usage de cet ref va particulièrement nous intéresser 
    const dialogRef = useRef<HTMLDialogElement>(null);

    const close = () => {
        dialogRef.current?.close();
    };

    useEffect(() => {
        const dialog = dialogRef.current;
        if (isOpen && !dialogRef.current?.open) {
            dialog?.showModal(); // 👈 usage propre à l'élément <dialog>
        } else {
            dialog?.close(); // 👈 usage propre à l'élément <dialog>
        }
    }, [isOpen]);

    return (
        <dialog
            ref={dialogRef}
            // 👇 capture l'élément 'close' et mise à jour de l'état du composant
            onClose={handleClose}
        >
            {children}

            <button 
                type="button" 
                onClick={close} 
                title="close modal" 
                aria-label="close modal"
                >
                close
            </button>
        </dialog>
    );
}

// App.tsx

function App() {
    const [isOpen, setIsOpen] = useState(false);
    const handleClose = (() => {
        setIsOpen(false);
    });

    const handleClick = (() => {
        setIsOpen(true);
    });

    return (
        <div>

            <Modal 
                isOpen={isOpen} 
                handleClose={handleClose}
            >
                {/* Le contenu de la modale */}
                <header>
                    <h1>Hello world</h1>
                    <small>pour être original...</small>
                </header>
            </Modal>


            <button
                type="button"
                onClick={handleClick}
            >
                Open modal
            </button>


            <p>{/* le petit Lorem Ipsum qui va bien 👌 */}</p>


        </div>
    );
}

Utilisation de l'élément`<dialog>` et `useRef`

L'élément <dialog> est une balise HTML permettant de créer des boîtes de dialogue modales avec une facilité déconcertante.

Il faut noter que cette balise bénéficie en outre d'un excellent support par les navigateurs modernes.

Pour créer une modale, il suffit d'encadrer le contenu de la modale avec le tag dialog.

<dialog>
    <p>Contenu de la modale</p>
</dialog>

Par défaut, la modale n'est pas visible, pour modifier son état le navigateur met quelques fonctions à notre disposition :

dialog.show(); // affiche l'élément comme une boîte de dialogue
dialog.showModal(); // affiche l'élément comme une modale
dialog.close(); // masque l'élément quelque soit s a nature

J'utilise alternativement les termes de "modale" et de "boîte de dialogue". Si besoin, cet article vous aidera à comprendre les différences entre boîte de dialogue et modale !

Nous utilisons useRef pour conserver une référence vers l'élément du DOM afin d'invoquer directement ces méthodes.

Contrôle de l'état d'ouverture / fermeture de la modale

La responsabilité relative à l'état d'affichage de la modale est partagée entre le composant Modal et son parent App.

Lorsque la propriété isOpen change, cela déclenche le hook useEffect lequel force l'élément dialog à rentrer dans l'état souhaité en invoquant soit la méthode showModal ou close.

Fausse bonne idée : gérer l'ouverture via css

Contrairement à d'autres solutions, ajouter ou retirer des classes css pour modifier l'affichage de la modale provoque des résultats assez mitigés.

Comme nous le verrons plus loin, la dialog embarque avec elle toute une logique d'accessibilité. Pour que le navigateur la gère au mieux, il est recommandé d'utiliser ces méthodes plutôt que de bricoler quelque chose de son côté 😁.

Synchroniser le DOM avec le contexte React

Si dialog.close() provoque la fermeture de la modale, cela ne concerne que la logique DOM. Pour synchroniser l'état de vos composants React, la solution consiste à écouter l'événement close émis par la dialog lors de sa fermeture.

 <dialog
    ref={dialogRef}
    // 👇 capture l'élément 'close' et invoque handleClose, lequel a pour responsabilité de mettre l'état du composant à jour
    onClose={handleClose}
>
    {/*...*/}
</dialog>

Donner du style à sa modale 😎

Deux choses intéressantes à noter :

Le pseudo élément ::backdrop : il représente le layer séparant le reste de la page de la modale. Ce pseudo élément présente l'avantage de lutter contre le fléau des DOM trop complexes.
La propriété css backdrop-filter : elle permet d'appliquer un filtre... sur le backdrop. 🤯

dialog::backdrop {
    background: rgba(50, 20, 100, 0.2);
    backdrop-filter: blur(2px);
}

Amélioration : Bloquer le scroll en arrière-plan

🛑 Stop ! Pas besoin de JS !

Si votre premier réflexe est de tenter de développer des scripts complexes pour bloquer les événements du navigateur... et bien vous commettriez la même erreur que moi ! 😱

Après des heures à développer un script robuste, j'ai finalement tout supprimé (sans regret !) en découvrant la ligne suivante :

html:has(dialog[open]) {
    overflow: hidden;
}

Tout est là.

Support de la fonctionnalité "click outside"

Implémentation

// Modal.tsx

//...
 function handleClickOutside(event) {
        if (!dialogRef.current) {
            return;
        }

        const box = dialogRef.current?.getBoundingClientRect();
        // On calcule si le curseur est à l'extérieur de la boîte englobante de la modale
        if (
            event.pageX < box.left ||
            event.pageX > box.right ||
            event.pageY < (box.top + window.scrollY) ||
            event.pageY > (box.bottom + window.scrollY)
        ) {
            close();
        }
    }
    // ...

    return (
        <dialog 
            ref={dialogRef} 
            onClose={handleClose}
            // 👇 On ajoute le handler "click outside" directement sur l'élément dialog
            onClick={handleClickOutside} 
        >
            // ...
        </dialog>
    );

Brancher l'écouteur "click-outside" sur l'élément dialog

Non, non, ce n'est pas une erreur : le "click outside" est bel et bien déclenché lorsqu'on clique sur la dialog 🙃.

En effet, le pseudo élément ::backdrop recouvre l'intégralité de la page, et comme il n'est pas possible de sélectionner des pseudos élément via l'api DOM, le navigateur estime que l'événement click doit être envoyé à l'élément dialog.

C'est pourquoi on écrit un brin de JS dans handleClickOutside pour vérifier si la souris se trouve réellement sur notre élément ou pas.

Augmenter la réutilisabilité avec un custom hook

Implémenter la logique de mise à jour de l'état en fonction de l'état d'ouverture de la modale peut vite être répétitif et agaçant.

Bonne nouvelle, React étant fait pour être agréable à utiliser, une solution à notre problème existe : les custom hooks.

function useModal() {
    const [isOpen, setIsOpen] = useState(false);
    const closeModal = (() => {
        setIsOpen(false);
    });

    const openModal = (() => {
        setIsOpen(true);
    });

    return {
        isOpen,
        closeModal,
        openModal
    };
}

function App() {
    const { isOpen, openModal, closeModal } = useModal();

    return (
        <div>
            <Modal 
                isOpen={isOpen}
                // 👇 on remplace handleClose par closeModal
                handleClose={closeModal}
            >
                {/* Le contenu de la modale */}
                <header>
                    <h1>Hello world</h1>
                    <small>pour être original...</small>
                </header>
            </Modal>


            <button
                type="button"
                // 👇 on remplace handleClick par openModal
                onClick={openModal}
            >
                Open modal
            </button>
            // ...
        </div>
    );
}

🛠 Précisions techniques, détails et conseils d'accessibilité

La balise <dialog> permet de créer très facilement aussi bien une boîte de dialogue classique, qu'une modale, le tout en résolvant plusieurs contraintes d'accessibilités pour nos.

Par défaut, elle se voit attribuer le rôle aria (aria-role) dialog.

Les différences concernant l'accessibilité seront surtout marquées par l'emploi de show ou de showModale, c'est-à-dire selon le type de widget souhaité.

Boîte de dialogue classique

S'ouvre avec la méthode show.
Ne gère pas automatiquement le contenu inerte. 👉**aria-hidden* ou inert permettra d'indiquer aux outils d'assistance qu'un contenu n'est plus visible / utilisable.*
Propriété aria-modal="false" (implicite et par défaut) indique que l'élément n'est pas modal.
Ne se ferme pas automatiquement lorsqu'on appuie sur Escape. De plus, si l'on souhaite implémenter ce type de comportement, bien penser à ne fermer que la dernière boîte de dialogue lorsqu'on appuie sur Escape

Les "vraies" modales

S'ouvre avec la méthode showModal.
Le contenu situé à l'extérieur de la modale est automatiquement considéré comme inerte.
Propriété aria-modal="true" ajoutée implicitement à l'élément. 👉 Combinée aux rôles **dialog* et alertdialog, elle rend inutile l'utilisation de aria-hidden sur le contenu extérieur de la modale car aria-modal indique aux technologies d'assistance que ce contenu est inerte.*
Se ferme automatiquement lorsqu'on appuie sur Escape.

Conclusion :

L'élément dialog offre une alternative accessible et légère pour la création de modale. Facilement adaptable, elle constitue à mes yeux une bonne approche contrairement aux grosses librairies qui, en présentant quantité de fonctionnalités, pénalisent finalement la page et l'application d'un code trop complexe et d'un DOM trop large, sans parler des soucis de maintenabilité sur le long terme lorsqu'on a trop de dépendances externes.

Modal vs Dialog : Comprendre les différences

Quentin Philippot — Tue, 23 May 2023 16:41:56 +0000

Lorsque vous concevez des interfaces ou effectuez des intégrations, vous avez sûrement croisé les termes "modale" et "boîte de dialogue" (dialog box).

Bien qu'ils soient souvent utilisés de manière interchangeable, il existe des différences subtiles entre ces deux concepts. Dans cet article, nous allons examiner ces différences pour vous aider à comprendre comment et quand les utiliser de manière appropriée.

Qu'est-ce qu'une modale ?

Commençons cet article par enfoncer des portes ouvertes ! 💥

Une modale est une fenêtre contextuelle qui apparaît au-dessus du contenu principal d'une application ou d'un site web. Elle est utilisée pour attirer l'attention de l'utilisateur sur une tâche ou une interaction spécifique, en bloquant temporairement l'interaction avec le reste de l'interface.

Les modales sont généralement utilisées pour des actions critiques ou des décisions importantes, nécessitant une attention immédiate de l'utilisateur.

Notez que cette définition n'est pas incompatible avec la possibilité de fermer automatiquement une modale lors d'un clic à l'extérieur de sa zone d'intérêt, ou du moins, tant que l'on s'assure que le click ne provoquera rien d'autre qu'une fermeture de modale.

Exemple d'une modale avertissant l'utilisateur d'une perte potentielle de donnée et lui proposant de les sauvegarder. Si le design est discutable, elle remplie en revanche assez bien son rôle de modale.

Qu'est-ce qu'une boîte de dialogue ?

Une boîte de dialogue (ou dialog box en anglais) est une fenêtre contextuelle utilisée pour afficher des informations, demander des confirmations ou obtenir des entrées de l'utilisateur.

Contrairement aux modales, les boîtes de dialogue ne bloquent pas nécessairement l'interaction avec le reste de l'interface. Elles peuvent être utilisées pour des interactions moins critiques, mais nécessitant tout de même une attention de l'utilisateur.

Boîte de dialogue permettant à l'utilisateur de sélectionner ses préférences relatives aux cookies. En bas de page et non bloquante, le développeur peut continuer à chercher ses solutions sans être perturbé par un affichage inutilement invasif.

Différences entre modale et boîte de dialogue

Maintenant que nous avons clarifié les distinctions entre les modales et les boîtes de dialogue, abordons un aspect crucial : l'accessibilité.

Assurer une expérience inclusive pour tous les utilisateurs, y compris ceux qui ont des besoins spécifiques, est essentiel.

Voici quelques conseils pratiques supplémentaires pour garantir que vos modales et boîtes de dialogue soient accessibles :

Comportement et accessibilité des boîtes de dialogue

Les boîtes de dialogue permettent une interaction simultanée avec le reste de l'interface (contrairement aux modales).
Elles doivent être bien étiquetées et fournir des instructions claires afin que les utilisateurs comprennent le but de la boîte de dialogue et les actions attendues. Cela passe par l'utilisation d'attributs comme arial-label et aria-description.
L'accessibilité des boîtes de dialogue peut être renforcée en veillant à ce que les contrôles et les éléments interactifs à l'intérieur de la boîte de dialogue soient clairement identifiés et atteignables via le clavier (gestion des éléments tabbable).

Comportement et accessibilité des modales

Les modales partagent les mêmes contraintes que les boîtes de dialogues, mais avec deux points supplémentaires : la gestion du contenu inerte et une navigation clavier plus restrictive.

Contenu inerte

Dès l'ouverture d'une modale, et jusqu'à sa fermeture, il devient impossible d'interagir avec le reste de la page. On parle alors de contenu inerte.

Voici quelques conseils pour marquer cette modification d'état :

Appliquer un changement visuel : ajout d'un layer (floutant, ou opaque) entre le contenu de la page et la modale.
Ajouter des indicateurs dédiés aux technologies d'assistances : l'ajout d'un champ aria-modal sur la modale permet d'indiquer l'état d'ouverture de celle-ci. Une ancienne solution consistait également à jongler avec l'attribut aria-hidden sur le contenu inerte.

Gestion de la navigation clavier

Il est essentiel de gérer correctement le focus clavier (gestion des éléments tabbable). Concernant la navigation clavier et la gestion du focus, voici les recommandations :

Déplacez automatiquement le focus clavier vers le contenu de la modale à l'ouverture.
La navigation clavier ne doit pas permettre à l'utilisateur de se déplacer hors de la modale.
Appuyer sur Tab permet de se déplacer sur le prochain élément tabbable.
Appuyer sur Shift + Tab permet de revenir le précédent élément tabbable.
Possibilité de fermer la modale en appuyant sur la touche Escape.

Des recommandations supplémentaires sont disponibles ici : https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/.

Confusion entre modale et dialog

En discutant avec d'autres développeurs et intégrateurs, je constate que ces différences restent parfois incomprises. Pourtant les règles d'accessibilités qui s'appliquent à ces éléments ne sont pas les mêmes, et confondre les deux mène souvent à des erreurs d'accessibilité.

Ce que n'est pas une modale

Note : cette section utilise des iframe vers d'autres pages d'exemples disponibles vers mon blog. Celles-ci étant bloquées sur dev.to, je vous invite à poursuivre la lecture sur le blog.

Prenons l'exemple suivant :

    /* CSS */
.hidden {
    display: none;
}

.modal__container:before {
    content:'';
    position: fixed;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
    background: blue;
    opacity: 0.5;
    pointer-events: none;
}

.modal__item {
    background: white;
    position: absolute;
    width: 50%;
    padding: 2rem 0;
    border-radius: 20px;
    margin: auto;
    left: 25%;
    top: 25%;
    text-align: center;
}

/* JS */
function toggleModal() {
    document.getElementById('demo-modal').classList.toggle('hidden');
}

<!-- HTML -->
<div id="content">
    <button
            type="button"
            onclick="alert('Je ne dois pas être cliquable lorsque une modale est ouverte')"
    >
        alert
    </button>
    <button
            type="button"
            onclick="toggleModal()"
    >
        toggle modal
    </button>
</div>

<div id="demo-modal" class="modal__container hidden">
    <div class="modal__item">
        <p>Je suis une modale</p>

        <button
                type="button"
                onclick="toggleModal()"
        >
            fermer
        </button>
    </div>
</div>

À première vue, l'élément qui s'affiche après avoir cliqué sur "toggle modal" ressemble à une modale. Toutefois, à cause de la propriété css pointer-event: none il est possible de cliquer sur le bouton "alert".

❌ Le contenu en arrière-plan n'est pas rendu inerte, ce qui est incompatible avec la définition donnée précédemment.

Bon, j'avoue que cet exemple est un peu absurde car cette propriété css n'a rien à faire là. 😇

Soit, retirons là et testons à nouveau !

Verdict ?

❌ Eh bien non, ce n'est pas une modale ! Le contenu n'est toujours pas inerte !

Si les clics cette fois interceptés, la navigation clavier reste néanmoins possible via la touche TAB. Il faut donc s'occuper de la gestion des éléments tabbable.

Pour désactiver ce comportement, on peut jouer avec l'attribut tabindex des éléments comme suivant :

    function toggleModal() {
    const modal = document.getElementById('demo-modal');

    const buttons = Array.from(document.querySelectorAll('#content button'));

    if (modal.classList.contains('hidden')) {
        // La modale est actualement cachée, elle sera donc afichée par le toggle 
        // On désactive le tab sur les boutons
        modal.setAttribute('tabindex', '0')
        buttons.forEach(btn => btn.setAttribute('tabindex', '-1'));
    } else {
        // La modale est actualement visible, elle sera donc cachée par le toggle 
        // On réactive le tab sur les boutons
        modal.setAttribute('tabindex', '-1');
        buttons.forEach(btn => btn.setAttribute('tabindex', '0'));
    }

    modal.classList.toggle('hidden');

}

Cette première version de modale mériterait encore plusieurs améliorations :

Utilisation d'attributs ARIA pour labeliser correctement la modale
La gestion des éléments tabbable n'est pas parfaite
etc.

Il existe beaucoup de sources pour apprendre à construire une modale accessible, et cela fera certainement l'objet d'un nouvel article.

Une erreur courante

Même si elle reprend les codes visuels de la modale (contenu arrière masqué, boîte de dialogue en premier plan), la "modale" du journal Le Monde permet une navigation clavier à l'extérieur de la modale.

Cette erreur se retrouve même sur les sites de grande envergure !

Malgré la volonté manifeste d'implémenter une modale (taille du widget, flou de l'arrière-plan), le contenu en arrière-plan n'est pas inerte à cause d'une mauvaise gestion des éléments tabbable.

Quels enjeux ?

Si ce type d'erreur peut sembler anodine, il faut garder en tête que le but d'une modale est de forcer une interaction avec l'utilisateur.

Ce type de widget est invasif et ne doit être utilisé à la légère : si l'utilisateur peut éviter l'interaction sans que cela ne pose de problème, alors le d'une modale n'est finalement peut-être pas adapté.

Dans notre exemple (modale de consentement RGPD), on peut raisonnablement de penser que soit le système de consentement présente des vulnérabilités, soit qu'un widget moins invasif pourrait répondre aux mêmes besoins sans dégrader l'expérience utilisateur (ce qui est le plus probable 😉).

Pour résumer, se tromper sur l'intégration d'une modale n'est pas une erreur critique, mais peut révèler :

Des axes / besoin d'améliorations sur l'accessibilité de votre site.
Des possibilités de scénarios d'échecs UX ou même software (selon les situations).
La possibilité d'améliorer l'expérience utilisateur en modifiant l'interface en passant d'une "modale dysfonctionnelle" à une "dialog box" ou tout autre widget moins invasif.

Conclusion

Il est important de comprendre les différences entre les modales et les boîtes de dialogue dans la conception d'interfaces.

Les modales sont adaptées aux actions critiques nécessitant une attention immédiate.
Les boîtes de dialogue conviennent à des interactions moins critiques mais nécessitant l'attention de l'utilisateur.

Pour garantir l'accessibilité, il est essentiel de rendre le contenu des modales inerte, de gérer correctement la navigation clavier et d'étiqueter clairement les boîtes de dialogue.

En respectant ces bonnes pratiques, nous pouvons offrir des expériences utilisateur inclusives.

En fin de compte, le choix entre une modale et une boîte de dialogue dépend du contexte et des besoins spécifiques. En comprenant ces concepts et en appliquant les bonnes pratiques, nous pouvons créer des interfaces performantes, accessibles et conviviales.

N'oublions pas que la conception d'interfaces accessibles est un processus continu qui nécessite une attention constante. En améliorant nos pratiques, nous pouvons offrir des expériences utilisateur de qualité.

Appliquez des filtres sur vos vidéos avec Javascript

Quentin Philippot — Tue, 11 May 2021 16:54:20 +0000

Appliquez des filtres sur vos vidéos avec Javascript

Que ce soit pour améliorer la netteté d'une image, rehausser sa luminosité, modifier la répartition des couleurs, ou pour des centaines de raisons toutes aussi fondées, la plupart des images affichées par nos écrans subissent de nombreux traitements.

En règle générale, ces corrections s'appliquent avant l'enregistrement des images sous forme de fichier (pour des raisons d'optimisations évidentes). Cela dit, il est parfois nécessaire d'appliquer des filtres sur un contenu vidéo en temps réel.

Comment retoucher des images à la volée ?

Je vous propose une solution très simple permettant d'effectuer ces traitements directement depuis notre navigateur.

Cette méthode peut se résumer ainsi :

Intégrer une vidéo la page, grâce à la balise <video> (idéalement en caché)
Récupérer son flux vidéo dans un objet ImageData
Effectuer le traitement de l'image dessus
Afficher le résultat dans une balise <canvas>.

Intégrer une vidéo à la page

 <video
   id="tuto-video"
   src="your-video-url"
   width="300"
   height="300"
   controls
></video>

Récupération du flux vidéo en JS

Si vous vous êtes déjà intéressés à l'encodage des vidéos, vous savez qu'obtenir un flux de pixels à partir d'un fichier est une tâche complexe. Pour parser les fichiers vidéos, maîtriser les différents formats est un indispensable.

« - Alors, nous allons devoir apprendre tous les formats vidéos pour continuer ? » 😨

Non, revenez ! Le navigateur s'occupe de tout !

Avec la balise <video>, extraire les pixels d'une vidéo se fait en seulement quelques lignes :

const video = document.getElementById('tuto-video');

// Create canvas for video's pixel extraction
const extractPixelCanvas = document.createElement('canvas');
const extractPixelContext = extractPixelCanvas.getContext('2d');

/**
 * @param {HTMLVideoElement} video
 * @param {Number} width 
 * @param {Number} height 
 * @return {ImageData} the pixel matrix
 */
function extractVideoImageData(video, width, height) {
    // avoid unnecessary resize as much as possible (optimization)
    if (extractPixelCanvas.width !==  width) {
        extractPixelCanvas.width =  width;
    }

    if (extractPixelCanvas.height !==  height) {
        extractPixelCanvas.height = height;
    }

    extractPixelContext.drawImage(video, 0, 0, extractPixelCanvas.width, extractPixelCanvas.height);
    return extractPixelContext.getImageData(0, 0, extractPixelCanvas.width, extractPixelCanvas.height);
}

Manipuler ses pixels avec `ImageData`

Pour afficher le contenu d'une matrice de pixel sur un écran, il suffit de l'injecter dans un contexte canvas :

canvasContext2D.putImageData(instanceOfImageData, 0, 0);

Quelques explications sur la classe `ImageData`

La structure de l'objet est relativement simple :

une instance possède les propriétés width et heightcorrespondant à la résolution de l'image.
Les pixels sont stockés dans la propriété data, une matrice de type Uint8ClampedArray.
Les pixels sont encodés sous forme RGBA. L'alpha est compris entre 0 et 255.

Pour modifier une image à la volée, on modifiera les pixels contenus dans data.

Un exemple tiré de la documentation.

// Iterate through every pixel
for (let i = 0; i < imageData.data; i += 4) {
    imageData.data[i + 0] = 0;    // R value
    imageData.data = 190;  // G value
    imageData.data = 0;    // B value
    imageData.data  // A value
}

Afficher une image retouchée dans un `<canvas>`

<!--html-->
<canvas id="tuto-canvas"></canvas>

//js
const canvas = document.getElementById('tuto-canvas');
canvasContext2D = canvas.getContext('2d');

const instanceOfImageData = applyYourAmazingFilter(/* ... */);

canvasContext2D.putImageData(instanceOfImageData, 0, 0);

Un filtre, oui ; mais aussi une animation !

L'utilisation d'un filtre sur un flux vidéo est considérée (ici) comme une animation.

L'implémentation du filtre et la modification des pixels font office de méthode de rendu, tandis que la synchronisation entre le canvas et le lecteur vidéo déterminera le comportement de la boucle de rendu.

Ces termes vous paraissent abstraits ? J'ai écrit un tutoriel sur ce sujet : Faîtes vos propres animations en JS.

Synchroniser l'animation avec le lecteur vidéo - Définir la boucle de rendu

L'animation doit se lancer lorsqu'on clique sur play, s'arrêter à la fin de la vidéo ou quand appuie sur pause (pour ne pas rafraîchir une image qui ne change pas, ce serait dommage de gâcher des ressources CPU pour rien).
En d'autres termes, la boucle de rendu doit être pilotée par le lecteur vidéo.

Pour rappel, la boucle de rendu s'occupe de rafraîchir automatiquement notre canvas.

const animation = new Animation({ /* … */ });

video.addEventListener('play', () => {
   animation.play();
});

video.addEventListener('pause', () => {
   animation.pause();
});

video.addEventListener('end', () => {
   animation.pause();
});

// render animation once when we click on timeline
video.addEventListener('timeupdate', () => {
   animation.askRendering()
});

Implémentation d'un filtre - Définir une méthode de rendu

Nous savons désormais comment extraire les pixels d'une vidéo et configurer la boucle de rendu. Il ne reste plus qu'à définir la méthode de rendu.

const animation = new Animation({
    canvas: document.getElementById('tuto-canvas'),
    // rendering method is here
    render: (context, canvas) => {
        const imageData = extractVideoImageData(video, canvas.width, canvas.height);
        // apply filter over imageData here;
        animation.clear();
        context.putImageData(imageData, 0, 0);
        }
    }
);

Ce tutoriel s'appuie sur une connaissance rudimentaire des canvas. Besoin d'une piqûre de rappel ? Cet article est un classique, de plus, il montre comment appliquer des filtres sur des images. Il constitue un excellent complément à ce tuto. N'hésitez pas à y jeter un œil ! 👍

Résumé

import Animation from '../../shared/animation.model';

document.addEventListener('DOMContentLoaded', () => {
    // Create canvas for video's pixel extraction
    const extractPixelCanvas = document.createElement('canvas');
    const extractPixelContext = extractPixelCanvas.getContext('2d');

    function extractVideoImageData(video, width, height) {
        // avoid unnecessary resize as much as possible (optimization)
        if (extractPixelCanvas.width !==  width) {
            extractPixelCanvas.width =  width;
        }

        if (extractPixelCanvas.height !==  height) {
           extractPixelCanvas.height = height;
        }


       extractPixelContext.drawImage(video, 0, 0, extractPixelCanvas.width, extractPixelCanvas.height);
       return extractPixelContext.getImageData(0, 0, extractPixelCanvas.width, extractPixelCanvas.height);
    }

    const video = document.getElementById('tuto-video');


    const animation = new Animation({
        canvas: document.getElementById('tuto-canvas'),
        render: (context, canvas) => {
            const imageData = extractVideoImageData(video, canvas.width, canvas.height);

            // apply filter over imageData here;

           animation.clear();
           context.putImageData(imageData, 0, 0);
       }
   });


    video.addEventListener('play', () => {
        animation.play();
    });

    video.addEventListener('pause', () => {
        animation.pause();
    });

    video.addEventListener('end', () => {
        animation.pause();
    });

    video.addEventListener('timeupdate', () => {
        animation.askRendering()
    })
});

Résultat préliminaire

« - Hein ? Je ne vois aucune différence… » 🙈

Précisément ! Nous n'avons encore appliqué aucun filtre. Toutefois, on constate que notre flux vidéo est bel et bien répliqué sans déformation ni latence.

Pour appliquer un filtre sur l'image, il suffira d'appliquer un traitement sur l'ImageData extraite dans la méthode de rendu.

Ce tutoriel pourrait s'arrêter là ; le mécanisme n'est guère plus compliqué. Toutefois, cela commence à peine à devenir cool, ne nous arrêtons pas en si bon chemin !

Exemple d'implémentation de filtres en JS

Grayscale

Nous allons simplement transformer les pixels RGB en niveau de gris.

// get grayscale value for a pixel in buffer

function rgbToGrayscale(buffer, offset) {
   return Math.ceil((
       0.30 * buffer[offset] +
       0.59 * buffer[offset + 1] +
       0.11 * buffer[offset + 2]
   ) * (buffer[offset + 4] / 255.0));
}

/**
* @param {Uint8Array} pixelBuffer
*/
function applyGrayscaleFilter(pixelBuffer) {
   for (let offset = 0; offset <pixelBuffer.length; offset += 4) {
       const grayscale = rgbToGrayscale(pixelBuffer, offset);
       pixelBuffer[offset] = grayscale;
       pixelBuffer[offset + 1] = grayscale;
       pixelBuffer[offset + 2] = grayscale;
       pixelBuffer[offset + 3] = 255;
   }
}


const animation = new Animation({
   canvas: document.getElementById('tuto-canvas'),
   render: (context, canvas) => {
       const imageData = extractVideoImageData(video, canvas.width, canvas.height);
       applyGrayscaleFilter(imageData.data);

       animation.clear();
       context.putImageData(imageData, 0, 0);
   }
});

Nous remplaçons les canaux RGB de chaque pixel par leur niveau de gris.

Intuitivement, il serait tentant de calculer une moyenne des composantes R, G et B et d'utiliser cette valeur comme niveau de gris. Toutefois, l'œil humain ne perçoit pas toutes les couleurs avec la même sensibilité. Et puisque nous sommes plus sensibles à certaines couleurs, il est tout naturel de donner plus d'importances à celles-ci lors du calcul du niveau de gris.

Cela explique la présence des constantes 0.30, 0.59 et 0.11 dans la méthode rgbToGrayscale. L'intensité obtenue par cette méthode est appelée la luminance du pixel.

Supporter les interactions souris

Une animation, c'est bien. Mais une animation qui interagit avec la souris, c'est mieux ! Transformons le code afin d'invoquer applyGrayscaleFilter seulement quand le pointeur se trouve au dessus du canvas.

const animation = new Animation({
    canvas: document.getElementById('tuto-canvas'),
    render: (context, canvas) => {
        const imageData = extractVideoImageData(video, canvas.width, canvas.height);

        // compute isPointerHoverCanvas ...

        if (isPointerHoverCanvas === false) {
            applyGrayscaleFilter(imageData.data);
        }

        animation.clear();
        context.putImageData(imageData, 0, 0);
    }
});

Déterminer la position de la souris par rapport au canvas

Il existe plusieurs façons de déterminer si le curseur est au-dessus d'un canvas. Selon l'approche, certaines sont plus appropriées que d'autres.

Dans cette situation, la plus simple consiste à :

Récupérer les coordonnées du canvas.
Calculer sa boîte englobante (ou hitbox)
Vérifier si les coordonnées du pointeur se trouvent dans la boîte englobante (collision AABB).

const pointerCoords = {x: 0, y: 0};

document.addEventListener('pointermove', event => {
    pointerCoords.x = event.clientX;
    pointerCoords.y = event.clientY;
});

const animation = new Animation({
    canvas: document.getElementById('tuto-canvas'),
    render: (context, canvas) => {
        // …

        const boundingBox = canvas.getBoundingClientRect();


        const isPointerHoverCanvas = (
            pointerCoords.x >= boundingBox.left &&
            pointerCoords.y >= boundingBox.top &&
            pointerCoords.x < boundingBox.right &&
            pointerCoords.y < boundingBox.bottom
        );


        if (isPointerHoverCanvas === false) {
            applyGrayscaleFilter(imageData.data);
        }
    }
});

On corse le jeu ! 🚀

On va appliquer le filtre grayscale sur toute l'image et ne faire apparaître les couleurs que sur les pixels autour de notre curseur.

Petite subtilité : pour créer un effet plus lisse, on déterminera un cercle à l'intérieur duquel les pixels seront colorés, mais avec une intensité inversement proportionnelle à la distance au centre…

Rappel géométrique

Un cercle peut être défini par un point (son centre), et un rayon. Dans notre cas, le centre du cercle correspond à la position du pointeur. Quant au rayon, nous prendrons une valeur arbitraire.

Déterminer si un point est dans un cercle revient à calculer la collision entre un point et un cercle.

Pour en savoir plus sur les méthodes de collision : http://www.jeffreythompson.org/collision-detection/point-circle.php

Approche générale

Pour chaque pixel, vérifions s'il est à l'intérieur du cercle autour du pointeur. Afin de faciliter le calcul, nous allons nous placer dans le repère géométrique de notre canvas. Les coordonnées ne seront plus exprimées en fonction de la page, mais de l'élément <canvas>.

render: (context, canvas) => {
    const imageData = extractVideoImageData(video, canvas.width, canvas.height);

    const coordsRelativeToCanvas = PointerCoordsHelper.getCoordsRelativeToElement(
        canvas,
        pointerCoords.x,
        pointerCoords.y
    );

    const buffer = imageData.data;

    // apply to the whole buffer, execept a circle defined by pointer position
    for (let offset = 0; offset < buffer.length; offset += 4) {
        const pixelOffset = (offset / 4); // pixels have 4 channel in ImageData
        const pixelX = pixelOffset % canvas.width;
        const pixelY = pixelOffset / canvas.width;

        // arbitrary radius
        const radius = 50;

        const isInCircle = CollisionHelper.isPointInCircle(
            pixelX, pixelY,
            coordsRelativeToCanvas.x, coordsRelativeToCanvas.y,
            radius
        );

        const grayscale = rgbToGrayscale(buffer, offset);

        if (isInCircle === false) {
            buffer[offset] = grayscale;
            buffer[offset + 1] = grayscale;
            buffer[offset + 2] = grayscale;
            buffer[offset + 3] = 255;
        } else {
            const distance = GeometryHelper.getDistanceBetween2DPoints(
                pixelX, pixelY,
                coordsRelativeToCanvas.x, coordsRelativeToCanvas.y
            );

            const weight = distance / radius;
            // apply a weight in order to let color intensity increase from the outside to the center
            buffer[offset] = weight * grayscale + (1 - weight) * buffer[offset];
            buffer[offset + 1] = weight * grayscale + (1 - weight) * buffer[offset + 1];
            buffer[offset + 2] = weight * grayscale + (1 - weight) * buffer[offset + 2];
            buffer[offset + 3] = 255;
        }
    }


    animation.clear();
    context.putImageData(imageData, 0, 0);
}

⚠️ Remarque sur le calcul de coordonnées (Niveau avancé) ⚠️

La position du curseur est exprimée relativement à notre canvas (l'origine du repère mathématique est le coin supérieur gauche du canvas).

On aurait pu implémenter le filtre en utilisant directement les coordonnées du pointeur dans la fenêtre (repère standard), mais les équations auraient étés plus compliquées.

De plus, la résolution du canvas (pixel théorique) et sa taille (pixel physique) peuvent parfois varier. Puisque l'algorithme itère sur les pixels théoriques du canvas (animation.context.width ou animation.canvas.width), pour supporter correctement ce type de situation, il faudra modifier les équations pour prendre en compte ce changement de repère supplémentaire…

Sa vision est basée sur le mouvement ! 🦖

Le filtre implémenté dans cet exemple n'affichera que les mouvements perceptibles entre deux frames.

« - Calculer les mouvements ? Ça à l'air difficile, non ? »

Tout dépend ce que l'on appelle mouvement. Pour notre exemple, calculer la différence deux pixels entre deux frame est largement suffisant !

Le principe pour calculer le mouvement entre deux frame N-1 et N :

Calculer le niveau de gris de la frame N-1
Calculer le niveau de gris de la frame N
Créer une image en niveau de gris correspondant à la valeur absolue de la différence des niveaux de gris des frame N et N - 1

Parce qu'un code vaut mieux que mille mots :

render: (context, canvas) => {
    const imageData = extractVideoImageData(video, canvas.width, canvas.height);
    const buffer = imageData.data;

    applyGrayscaleFilter(buffer);

    // first rendering
    if (lastBuffer === null) {
        lastBuffer = buffer.slice(0);
        window.lastBuffer = lastBuffer;
        return;
    }

    // compute movement
    const diffBuffer = new Uint8Array(buffer.length);

    for (let offset = 0; offset < buffer.length; offset += 4) {
        diffBuffer[offset] = Math.abs(buffer[offset] - window.lastBuffer[offset]);
        diffBuffer[offset + 1] = Math.abs(buffer[offset + 1] - window.lastBuffer[offset + 1]);
        diffBuffer[offset + 2] = Math.abs(buffer[offset + 2] - window.lastBuffer[offset + 2]);
        diffBuffer[offset + 3] = 255;
    }

    // update "last" buffer
    window.lastBuffer = buffer.slice(0);

    // overwrite image data in order to browse only the differences between the two frames
    diffBuffer.forEach((value, index) => {
        imageData.data[index] = value;
    });

    animation.clear();
    context.putImageData(imageData, 0, 0);
}

« - Mouais, avouons que c'est pas terrible... » 😞

En effet, on peut mieux faire ! Néanmoins, concentrons-nous sur le positif : nous avons un début de quelque chose !

Nous parvenons à déceler les contours du perroquet lorsqu'il effectue un mouvement. Mais ses déplacements sont lents, peu perceptibles d'une frame sur l'autre.

De plus, le taux de rafraichissement étant relativement élevé (60 fps), nous effectuons un rendu approximativement toutes les 16ms. Les mouvements ne sont donc perceptibles que durant ce laps et temps et sont oubliés au rendu suivant.

Sachant que la persistance rétinienne est de l'ordre de 1/25 de secondes (40 ms), pour avoir un rendu plus fidèle, il faudrait garder en mémoire l'image des 40 dernières ms, et les prendre en compte dans notre calcul du mouvement.

Amélioration simple

Plutôt que de se lancer dans un calcul périlleux sur le taux de rafraîchissement optimal, nous allons opter pour une solution bête et méchante : calculer le mouvement en prenant en compte, non pas la dernière frame, mais les X dernières frames.

function computeMovement(target, newFrame, oldFrame) {
    let offset = 0;
    const length = newFrame.length;

    // another version of for-loop to compute movement
    while (offset < length) {
        target[offset] = Math.abs(newFrame[offset] - oldFrame[offset]);
        target[offset + 1] = Math.abs(newFrame[offset + 1] - oldFrame[offset + 1]);
        target[offset + 2] = Math.abs(newFrame[offset + 2] - oldFrame[offset + 2]);
        offset += 4;
    }
}

/**
 * check previous frame difference and apply a weight 
 * @return Uint8Array buffer with some extra movement pixel to add
 */
function computePersistance(buffer) {
    /*** @var {Number} historyLength is a global var, it's the number of frame to consider ***/
    let indexedHistoryBuffer = Array(historyLength);
    let weights = Array(historyLength);

    for (let k = 0; k < historyLength; k++) {
        indexedHistoryBuffer[k] = getHistoryBuffer(k);
        weights[k] = state.persistanceFactor * (k / historyLength);
    }

    const length = buffer.length;
    let pixelOffset = 0;
    let historyBufferOffset, historyBuffer;
    let c1, c2, c3, c4;

    while (pixelOffset < length) {
        c1 = pixelOffset;
        c2 = c1 + 1;
        c3 = c2 + 1;
        c4 = c3 + 1;

        buffer[pixelOffset] = 0;
        buffer[c2] = 0;
        buffer[c3] = 0;
        buffer[c4] = 255;

        historyBufferOffset = historyLength - 1;

        while (historyBufferOffset >= 0) {
            historyBuffer = indexedHistoryBuffer[historyBufferOffset];
            buffer[pixelOffset] += weights[historyBufferOffset] * historyBuffer[pixelOffset];
            buffer[c2] += weights[historyBufferOffset] * historyBuffer[c2];
            buffer[c3] += weights[historyBufferOffset] * historyBuffer[c3];

            historyBufferOffset--
        }

        pixelOffset++;
    }
}

Remarques :

Afin d'appliquer notre facteur de persistance on se base directement sur les différences calculées lors des rendus précédents.
Pour éviter d'instancier une trop grande quantité de buffers, nous utilisons un pool d'instances que nous gérons grâce à getHistoryBuffer

render: (context, canvas) => {
    const imageData = extractVideoImageData(video, canvas.width, canvas.height);
    const buffer = imageData.data;
    applyGrayscaleFilter(buffer);

    // first rendering
    if (lastBuffer === null) {
        lastBuffer = buffer.slice(0);
        window.lastBuffer = lastBuffer;
        return;
    }

    const diffBuffer = new Uint8Array(buffer.length);
    const persistanceBuffer = new Uint8Array(buffer.length);

    computeMovement(diffBuffer, buffer, window.lastBuffer);
    computePersistance(persistanceBuffer);

    shallowCopy(lastBuffer, buffer);

    // clamp sum of diffs 
    for (let offset = 0; offset < buffer.length; offset += 4) {
        buffer[offset] = Math.ceil(Math.min(255, diffBuffer[offset] + persistanceBuffer[offset]));
        buffer[offset + 1] = Math.ceil(Math.min(255, diffBuffer[offset + 1] + persistanceBuffer[offset + 1]));
        buffer[offset + 2] = Math.ceil(Math.min(255, diffBuffer[offset + 2] + persistanceBuffer[offset + 2]));
        buffer[offset + 3] = 255;
    }

    let currentHistoryBuffer = diffHistory[state.currentOffset];
    shallowCopy(currentHistoryBuffer, diffBuffer);

    state.currentOffset = nbFrameRendered % historyLength;


    animation.clear();
    context.putImageData(imageData, 0, 0);
}

Remarques :

Lorsqu'on additionne des buffers, ne pas oublier d'effectuer un clamp afin de s'assurer que les valeurs additionnées restent dans l'intervalle des valeurs autorisées par la structure de donnée (entre 0 et 255).
La méthode shallowCopy se contente d'effectuer une copie superficielle d'un tableau dans un autre tableau. Le but est de réutiliser les instances existantes et d'éviter la répétition de code. Son implémentation est triviale et disponible sur le git.

Voici une tentative se basant sur les 5 dernières frames, avec coefficient équivalent à 15. Si les mouvements sont davantages perceptibles, le coût en calcul lui est nettement plus élevé. On passe de 60 fps à un peu plus de 20 fps. Rien de plus normal, on a presque triplé la charge de travail.

Il existe des méthodes permettant d'obtenir un résultat plus propre et moins gourmant en calcul, mais également moins simple à expliquer 😁.

Puisque le but de cet article est de présenter des filtres simples, je les passe sous silence. Cela fera peut-être l'objet d'un prochain tutoriel.

La vie en bleu 🦜

Dans ce dernier exemple, je propose de teindre ce cher perroquet en bleu.

Pour atteindre notre objectif, considérons la couleur de son plumage d'origine. Il n'est pas simplement rouge, mais couvre une nuance de rouge. Le filtre devra prendre en compte toutes ces nuances, pour proposer un rendu réaliste prenant en compte la pigmentation naturelle des plumes ainsi que les variations de luminosité.

Rappel sur la représentation de la couleur

La représentation des couleurs dans les ImageData est en RGBA. En d'autres termes, la couleur finale est obtenue à partir d'un mélange des quatre composantes.

Une solution naïve consisterait à supprimer la dimension rouge (mettre toutes les intensités à 0). Le défaut de cette représentation (RGBA), toutes les couleurs ont une part contiennent une part de rouge. Autrement dit, si l'on modifie la composante R, quasiment toutes les couleurs seront impactées.

Bonne nouvelle : il existe énormément d'espaces couleurs et dont la plupart ne sont pas couplés à la couleur rouge ! Des formules mathématiques permettent de changer facilement de représentation, il n'y a donc aucune raison de se borner à ce bon vieux RGB.

Selon le cas d'usage, certains espaces couleurs sont plus pratiques que d'autres (YCrCb pour la compression, CMJN pour l'impression, etc).

Dans le cas présent, l'ensemble HSL Hue Saturation Lightness, ou TSV en français semble le plus approprié. Dans cet espace, la teinte des couleurs est définie via un cercle colorimétrique.

Pour transformer du "rouge" en "bleu", il suffit de déterminer une section du cercle que l'on souhaite remplacer et d'y coller la section par laquelle on souhaite le remplacer.

Principe du filtre

Récupérer la couleur des pixels RGBA.
Les convertir en HSL.
Manipuler les teintes rouges et les remplacer par des bleues.
Reconvertir en RGBA.
Remplir l'instance ImageData avec les pixels modifiés.

Implémentation

Concernant les fonctions de transformations HSL vers RGBA et réciproquement, je vous laisse checker le git.

Pour des raisons de performances, nous allons implémenter une Look Up Table (LUT), c'est-à-dire une table de correspondance pour toutes nos couleurs. L'enjeu est de ne pas calculer toutes les correspondances de couleurs à la volée (pixels par pixels à chaque rendu), mais de les calculer une bonne fois pour toutes au lancement de la page.

La méthode de rendu n'aura qu'à lire dans cette LUT pour y lire les résultats et gagner un temps précieux (et un meilleur frame rate).

Calcul de la LUT

function generateRedToBlueLUT() {
    const size = 16777216; // 256 * 256 * 256
    const lut = new Array(size);

    // initialize all colors to black
    for (let i = 0; i < size; i++) {
        lut[i] = [0, 0, 0];
    }

    // iterate through RGB combinaisons
    for (let redOffset = 0; redOffset < 256; redOffset++) {
        for (let greenOffset = 0; greenOffset < 256; greenOffset++) {
            for (let blueOffset = 0; blueOffset < 256; blueOffset++) {
                // Use a pool design pattern
                // If you want to implements it without object pool, juste replace it by [0, 0, 0]
                const rgb = vec3Pool.getOne();
                const hsl = vec3Pool.getOne();

                rgb[0] = redOffset;
                rgb[1] = greenOffset;
                rgb[2] = blueOffset;

                // color conversion, check sources for detailled implementation 
                rgbToHSL(rgb, hsl);

                // Clamp saturation and lightness
                hsl[1] = Math.max(0, Math.min(hsl[1], 1));
                hsl[2] = Math.max(0, Math.min(hsl[2], 1));

                // Here is the trick: hue is represented by a degree angle
                // We want : 0 <= hue < 360
                if (hsl[0] < 0) {
                    hsl[0] += 360;
                }

                hsl[0] = hsl[0] % 360;

                // Assume that :
                // - "red" hues are between 340° and 20°
                // - "blue" are between 140° and 220°

                // replace hue
                if (hsl[0] > 340 && hsl[2] < 0.85) {
                    hsl[0] -= 120;
                }

                else if (hsl[0] < 20 && hsl[2] < 0.85) {
                    hsl[0] += 240;
                }

                // sanitize angle : 0 <= hue < 360 
                if (hsl[0] < 0) {
                    hsl[0] += 360;
                }

                hsl[0] = hsl[0] % 360;

                hslToRGB(hsl, rgb);

                // store RGBA converted into lut
                lut[redOffset * 65536 + greenOffset * 256 + blueOffset] = Array.from(rgb);

                // recycle instance, only for object pool implementation
                vec3Pool.recycle(rgb);
                vec3Pool.recycle(hsl);
            }
        }
    }

    return lut;
}
window.lut = generateRedToBlueLUT();

Plusieurs remarques sur cette implémentation :

Notre LUT est un tableau. On calcule l'index de chaque couleur par la formule R * 255 * 255 + G * 255 + B
Pour des raisons de performances, on utilise un object pool design pattern. Le calcul d'une LUT demande d'instancier pas mal de petits tableaux, cela peut surcharger inutilement la mémoire du navigateur. Pour en savoir plus sur l'implémentation de l'object pool design pattern en JS, lisez l'article suivant : Optimisez vos applications JS avec l'Object Pool Design Pattern !
Les calculs d'angles sont empiriques, à partir du cercle colorimétrique. D'ailleurs, en regardant attentivement le rendu, on peut s'apercevoir que la "teinture" n'est pas parfaite et que quelques pointes de rouges se promènent ça et là 😉

Coup d'oeil sur la méthode de rendu

render: (context, canvas) => {
    const imageData = extractVideoImageData(video, canvas.width, canvas.height);
    const buffer = imageData.data;

    for (let offset = 0; offset < buffer.length; offset += 4) {
        const r = buffer[offset];
        const g = buffer[offset + 1];
        const b = buffer[offset + 2];

        // 65536 = 256 * 256
        const lutIndex = r * 65536 + g * 256 + b;

        // just replace color by pre-computed value
        const color = window.lut[lutIndex];

        buffer[offset] = color[0];
        buffer[offset + 1] = color[1];
        buffer[offset + 2] = color[2];
        buffer[offset + 3] = 255;

    }

    animation.clear();
    context.putImageData(imageData, 0, 0);
}

Et voici un beau perroquet haut en couleur ! :D

Conclusion

J'espère sincèrement que ce tutoriel vous a plu. Le principe derrière l'utilisation de filtres en live est assez simple à implémenter, mais nécessitait bien selon moi quelques exemples pour comprendre son utilisation. Je suis passé assez rapidement sur certains points pour éviter de dévier du sujet principal : ~~torturer ce pauvre oiseau~~ utiliser une boucle de rendu pour appliquer des filtres en temps réels.

N'hésitez pas à me faire part de vos commentaires ou de vos remarques, c'est toujours un plaisir 😉

Photo de couverture créée par Anthony

Faites vos propres animations en JS

Quentin Philippot — Wed, 11 Nov 2020 10:06:25 +0000

Dans cet article, nous allons comparer plusieurs méthodes permettant de faire des animations en JavaScript.

L'approche intuitive

Une animation, ce n'est qu'une succession d'images dans le temps. De fait, pour créer une animation, il suffit d'effectuer un rendu à intervalle régulier. Facile, non ? 😄

Si toutefois un exemple était nécessaire, animons sans attendre la scène suivante : un cercle blanc se déplaçant horizontalement dans un canvas.

const canvas = document.querySelector('canvas');
const _2PI = 2 * Math.PI;


function setupCanvas(canvasElement) {
    canvasElement.width = window.innerWidth;
    canvasElement.style.width = window.innerWidth + 'px';

    canvasElement.height = window.innerHeight;
    canvasElement.style.height = window.innerHeight + 'px';

    const ctx = canvasElement.getContext('2d');
    ctx.strokeStyle = 'rgba(255, 255, 255, 0.2)';
    ctx.lineWidth = 1;

    ctx.fillStyle = 'rgb(255,255,255)';

    return ctx;
}

const context = setupCanvas(canvas);


var x = 50;
var y = 50;

var duration = 4000;
// Rendering loop interval
setInterval(function() {
    // logic of our animation
    window.clear();
    var now = Date.now();

    x = ((now % duration) / duration * canvas.width);

    // draw circle
    context.beginPath();
    context.arc(x, y, 30, 0, _2PI);
    context.closePath();
    context.fill();
    context.stroke();
}, 16);

Résultat :

Notez qu'une telle animation aurait très bien pu être réalisée en HTML/CSS, et qu'une implémentation reposant sur un canvas peut s'apparenter - selon certains - à atomiser une mouche avec un bazooka 💣

Toutefois, puisque nous allons complexifier nos animations dans la suite de l'article, autant partir sur de bonnes bases !

La boucle de rendu

Avant de gérer des animations plus complexes, il semble opportun d'introduire un concept clé : la boucle de rendu ou rendering loop.

Il s'agit d'un mécanisme utilisée pour rendre notre animation, similaire à la boucle de jeu dans le contexte des jeux-vidéo.

Pour gagner en lisibilité, nous allons isoler la logique propre au rendu de l'animation dans une méthode nommée render.

function render() {
 // logic of our animation
    window.clear();
    var now = Date.now();

    x = ((now % duration) / duration * canvas.width);

    // draw circle
    context.beginPath();
    context.arc(x, y, 30, 0, _2PI);
    context.closePath();
    context.fill();
    context.stroke();
}

// rendering loop
setInterval(render, 16);

Cette modification paraît anodine, pourtant nous venons de faire un pas de géant ! 🚀

Nous disposons désormais d'une méthode de rendu render invoquée en boucle, ou pour être plus formel, d'une boucle de rendu.

Boucle de rendu, méthode de rendu, quelle différence ?

Les deux entités sont très liées, mais se différencient par la nature de leur préoccupation :

La méthode de rendu contient la logique propre au rendu de nos objets. Elle répond à la question : "Comment gérer l'apparence mes objets ?".
La boucle de rendu contient la logique propre au séquençage des rendus. Elle répond à la question : "Comment planifier l'affichage de mes objets ?"

Nous le verrons, chacun de ses deux aspects nous expose à des problématiques différentes 👍.

Gérer le cycle de rendu

Une façon de mesurer les performances d'une animation consiste à analyser son frame rate. Le frame rate se mesure en FPS (Frame Per Seconds) et représente nombre d'images que notre animation affiche par seconde.

Pour considérer qu'une animation est fluide, nous considérerons que :

Le frame rate doit idéalement se situer autour des 60 FPS (soit une image toutes les 16 ms).
Le frame rate doit être stable pour que l'impression de mouvement soit cohérente. Une variation soudaine peut entraîner une sensation de ralentissement ou de saccade. Passer subitement de 60 fps à 30 fps provoquera un ressentit généralement plus désagréable qu'une animation constante à 30 fps, bien que son score moyen de fps soit presque 2x plus grand !

En réalité, le problème est beaucoup plus complexe ! J'ai volontairement simplifié pour les besoins de l'article, mais si vous souhaitez en savoir plus sur l'impression de mouvement et le traitement des images, je ne peux que vous recommander cet excellent article 🤓 : the-illusion-of-motion

Voici les modifications à apporter à notre code pour calculer le frame rate :

let nbRender = 0;

// every seconds prompt frame-rate, then reset counter
setInterval(function() {
    console.log('fps:' + nbRender);
    nbRender = 0;
}, 1000);

// Rendering loop interval
setInterval(function() {
  nbRender++;
  render();
}, 16);

Notez combien la modification est simple. Grâce au découplage du code via la méthode de rendu, la logique propre au rendu de nos objets n'a pas été impactée 🧐.

En rejouant notre script, on constate que l'animation tourne autour de 60FPS. Si l’on diminue le délai de notre intervalle (de 16ms à 10 ms par exemple), la boucle de rendu sera plus souvent évaluée, et l'on obtiendra un frame rate plus élevée…

Enfin, en théorie !

Limitation des méthodes de rendues reposant sur un intervalle

Attention : tous les navigateurs ne se valent pas. La façon dont ils gèrent les intervalles peut varier. Google Chrome notamment tire son épingle du jeu et minimise l'impact des limitations listées ci-après.

Intervalles non réguliers et drift

Rien ne garantit que le délai renseigné un setInterval sera scrupuleusement respecté. Ce temps ne correspond pas à "dans combien de temps le callback sera exécuté", mais à la durée minimale avant que celui-ci soit invoqué.

Surpris ? Pourtant, rien de plus logique ! Les navigateurs exécutant le code JS en mono-thread, si le moteur JS est déjà occupé au moment traiter le code contenu dans notre intervalle, il nous faudra attendre qu'il termine sa tâche actuelle avant de s'intéresser à notre intervalle.

À chaque itération, notre intervalle peut accumuler du retard. Si bien qu'un intervalle initialisé au temps 0ms avec 100ms de délais entre chaque itération, pourrait avoir lieu au temps 100...548 ms !

C'est ce déphasage que l'on désigne par "drift".

Dans le cadre d'une animation, selon la charge de l'application web, on peut "perdre des frames" en cours de route. Cela peut être gênant si notre boucle de rendu implémente une partie de la logique métier de l'application.

Cet article détaille comment les timers JavaScript fonctionnent, et pourquoi ils ne sont pas fiables : how-javascript-timers-work.

Des problèmes de performances historiques

Il y a encore quelques années il existait une différence palpable entre les performances d'une animation reposant sur setInterval ou sur les requestAnimationFrame.

Je ne prends même pas la peine de vous proposer de lien vers un article. Il y en a des centaines. La plupart sont très bien détaillés.

⚠️ De nos jours cet écart a tendance à s'estomper. À l'heure où j'écris cet article, je n'ai pas réussi à mesurer de différence significative entre les deux méthodes.

La méthode window.requestAnimationFrame

Afin de contourner tous ces problèmes, les navigateurs implémentent une méthode nommée requestAnimationFrame (parfois abrégée rAF).

Plutôt que de planifier des rendus à intervalle régulier, nous déléguons cette responsabilité au navigateur. D'un coup d'un seul, nous nous débarrassons des problèmes liés à la logique propre au séquençage des rendus.

Parmi les services rendus par les requestAnimationFrame, on peut noter :

Elles adaptent le frame rate en fonction de l'écran de l'utilisateur. Après tout, pourquoi s'acharner à calculer 60 images par seconde si notre installation n'est capable d'en afficher que 50 ?
La boucle de rendu s'arrête dès que la page n'est plus visible (changement d'onglet, passage en arrière-plan, etc). Cela évite une consommation inutile de ressources et préserve la batterie des appareils mobiles.
Elles ne reposent pas sur un système de timer, nous ne rencontrons donc pas de problème de drift.
Les images sont calculées les unes à la suite des autres, on évite de tomber dans un goulot d'étranglement.

Sans plus attendre, voyons comment modifier notre boucle de rendu pour utiliser les requestAnimationFrame :

function renderingLoop () {
  nbRender++;
  render();

  // ask a new rendering
  window.requestAnimationFrame(renderingLoop);
});

window.requestAnimationFrame(renderingLoop);

C'est tout ? Oui 😌.

Notez (une fois de plus !) que les modifications auraient étés bien plus complexes si nous n'avions pas pris la peine de séparer la boucle de rendu et la méthode de rendu en deux entités distinctes.

Interagir avec une animation

Une bonne animation, ça peut être chouette. Mais, une animation avec laquelle on peut interagir, c'est carrément mieux !

Mettre en pause / reprendre une animation

Il suffit d'introduire un boolean isPlaying indiquant si un rendu doit être effectué ou non. Ce n'est pas bien sorcier, toutefois une subtilité requiert votre attention. Je vois bien souvent des implémentations comme :

var animation = function() {
    window.requestAnimationFrame(animation);
    if (animation.isPlaying !== false) {
         render();
    }
}

ou si on utilise des intervalles :

setInterval(function() {
    if (isPlaying === true) {
        render();
    }
}, 16);

Soyez vigilant : suspendre le rendu ne signifie pas interrompre la boucle de rendu. Votre application cessera certes de calculer de nouvelles frames, mais votre boucle de rendu continuera à tourner dans le vide.

Ce n'est pas très élégant, et cela peut parfois vous jouer des tours.

Voici comment interrompre proprement la boucle de rendu :

var animation = function() {
    if (animation.isPlaying !== false) {
        window.requestAnimationFrame(animation);
        render();
    }
};

animation.pause = function() {
    animation.isPlaying = false;
};

animation.play = function() {
    animation.isPlaying = true;
    window.requestAnimationFrame(animation);
}



var animationIntervalId = null;

function play() {
    if (animationIntervalId === null) {
        animationIntervalId = setInterval(function() {
           render();
    }, 16);
    }
}

function pause() {
    if (animationIntervalId !== null) {
        clearInterval(animationIntervalId);
        animationIntervalId = null;
    }
}

Interagir avec la souris (ou le clavier)

Soit l'animation suivante :
(Adaptée pour les besoins depuis le benchmark de @nukadelic)

On ne va pas rentrer dans le détail de son implémentation. Pour les curieux, jetez un coup d'œil sur le repository git.

Nous souhaitons modifier son comportement afin de faire apparaître un cercle rouge à l'emplacement de la souris. Si le curseur bouge, le cercle se déplacera en conséquence.

// Attention : à ne surtout pas faire !
document.addEventListener('mousemove', function(event) {
    render(context);

    // compute coordinate into canvas
    var bb = event.target.getBoundingClientRect();
    var x = event.clientX - bb.left;
    var y = event.clientY - bb.top;

    context.fillStyle = "rgba(255,0,0,0.5)"
    context.beginPath();
    context.arc(x,y, 10 ,0,6.283185,0,true);
    context.fill();
});

Horreur, nos FPS baissent drastiquement ! Très vite, la page a crashée. Je n'ai même pas pu prendre un gif pour illustrer la situation 😢.

Analyse du problème

Une indigestion d'événements

Chaque déplacement du curseur lance un événement mousemove, et appelle render().

L'ennui c'est qu'en déplaçant physiquement votre souris, ce n'est pas un, mais plusieurs centaines d'événements qui sont lancés en quelques secondes, et autant de demandes de rendus ! 🤯

Une machine idéale - disposant d'une capacité de calcul et des ressources mémoire infinies - résisterait à une telle charge de travail. L'animation serait alors d'une fluidité exemplaire. Le frame-rate atteindrait un pic équivalent à plusieurs centaines de FPS.

En pratique, aucun navigateur n'est capable de suivre la cadence.

Le problème dépasse le simple cadre des animations : plus le callback associé à un événement fréquent est complexe, plus l'expérience utilisateur est dégradée.

L'Event Loop.

La gestion des événements JavaScript est en mono-thread.

Quand un utilisateur déplace son curseur, les mousemove sont mis dans une file d'attente et traité un par un. Dans le cas d'une animation, plusieurs centaines de rendus sont mis en attente.

Si vous souhaitez en apprendre davantage sur l'Event Loop, je recommande cet article : https://felixgerschau.com/javascript-event-loop-call-stack

« Et alors ? Si JavaScript est mono-thread, et qu'il effectue mes rendus un par un, tout devrait fonctionner correctement. Je ne vois pas où est le problème ! »

Supposons que chaque frame requiert 20 ms pour être affichée. Puisque le rendu est séquentiel, si déplacer le curseur jette 1000 événements mousemove, le script commandera le calcul de 1000 frames.

Le programme consacra donc 20 secondes pour retranscrire un mouvement de souris ayant pourtant duré moins d'une seconde ! ☠️

Le fait que l'exécution du JS soit en mono-thread ne signifie pas qu'il évolue dans un thread dédié. Loin de là !

Le processus responsable de notre JS s'occupe aussi de la réactivité de la page. Noyer le processus (main-thread) aboutira à une expérience utilisateur dégradée (le plantage pur et simple de votre page n'est pas exclu).
https://developer.mozilla.org/en-US/docs/Glossary/Main_thread

De façon générale, dès que le temps de rendu est supérieur à la durée de vie de votre frame, votre animation en pâtit. Au mieux elle saccade (le moteur de rendu "sacrifie" des demandes de rendu).

Dans le pire des cas l'animation est désynchronisée, car toutes les demandes de rendu sont exécutées. Les interactions de l'utilisateur sont rendues avec un décalage dû au temps de calcul élevé. Une autre possibilité est un mélange des deux à coup de grand "freeze" d'écran. Rien de bien souhaitable !

Solution

Lors d'une interaction provenant de l'utilisateur, modifiez seulement l'état de vos objets. N'effectuez surtout pas de rendu. C'est le job de la boucle de rendu, et elle le fait très bien.

Dans cet exemple "modifier l'état de l'objet" signifier simplement rafraîchir les coordonnées du cercle.

// rendering method 
function render(context) {
   var radius= 25;
   // only draws circles with something like that:
   for (var i = 0; i < circles.length; ++i) {
    context.beginPath();
    context.arc(circle[0], circle[1], radius, 0, _2PI);
    context.fill();
    context.stroke();
  }
}

// rendering-loop
var animation = function() {
    window.requestAnimationFrame(animation);

    window.clear(raf);
    render(raf.context);
}

animation();

document.addEventListener('mousemove', function(event) {
    // compute coordinate into canvas
    var bb = event.target.getBoundingClientRect();
    // Assume the following :
    // - mouseCircle refer a circle
    // - mouseCircle[0] means x position 
    // - mouseCircle[1] means y position 
    mouseCircle[0] = event.clientX - bb.left;
    mouseCircle[1] = event.clientY - bb.top;
});

Encore une fois, cela se traduit par une séparation de la logique business et la logique de rendu. Dans notre listener, on met seulement à jour la position de notre cercle (logique business), et on laisse notre boucle de rendu s'occuper du reste. Automatiquement, lorsqu'elle effectuera son rendu, elle dessinera mouseCircle avec ses nouvelles coordonnées.

Conclusion

Créer une animation basique est assez intuitif. Néanmoins, il existe quelques règles permettant de développer plus facilement et éviter des problèmes de performances ou de maintenabilité.

Créer une méthode de rendu et une boucle de rendu afin de faciliter le cycle de vie de vos animations.
La méthode de rendu décrit comment gérer l'apparence de mes objets à afficher
La boucle de rendu planifie l'affichage de mes objets, elle décide quand invoquer la méthode de rendu.
La méthode de rendu a pour vocation de décrire comment afficher vos objets. Si l'utilisateur peut interagir avec l'animation, éviter au maximum de modifier vos objets à l'intérieur de celle-ci.
Implémenter une boucle de rendu avec setInterval présente de nombreux défauts : taux de rafraîchissement non adaptatif, drift, mauvaise gestion parfois chaotiques des intervalles en arrière-plan par le navigateur, fuites mémoires car on oublie 9 fois sur 10 de récupérer l'intervalId retourné par setInterval (avouons-le 😇), etc.
Il est recommandé d'utiliser les requestAnimationFrame. Les navigateurs gèrent les demandes de rendu selon leur besoin et s'adaptent au contexte d'exécution.

Le mot de la fin

Ceci clôture mon deuxième tutoriel sur le JavaScript 😁. N'hésitez pas à poster dans les commentaires vos expériences avec les animations en JavaScript !

Optimisez vos applications JS avec l'Object Pool Design Pattern !

Quentin Philippot — Tue, 22 Sep 2020 17:28:29 +0000

Parfois méconnu des développeurs junior, l'object pool est un patron de conception fréquemment utilisés lorsqu'on manipule un grand nombre d'instances.

Indépendamment de votre langage de prédilection, vos chances de le rencontrer sont loin d'être dérisoires. Que vous soyez développeur Web, Mobile, ou que vous luttiez tous les jours contre un langage de bas niveau, ce design pattern s'adresse à vous ! 😉

Qu'est-ce que l'Object Pool design pattern ?

Ce patron de conception repose sur la réutilisation massive d'instances. Le concept est simple : au lieu de laisser notre programme détruire nos objets lorsqu'ils ne sont plus utiles, on les place dans une réserve d'instance : la pool.

Ainsi, dès que notre application aura à nouveau besoin d'une instance de même type, au lieu d'en créer une, il suffira simplement d'en piocher une dans notre pool. C'est tout.

Rappel sur la gestion mémoire ⚙️

Principe général

Tout au long de son exécution, un programme manipule toute sorte d'objet et de structure de données plus ou moins complexe. Pour créer une nouvelle instance, il effectue une allocation mémoire, c'est-à-dire qu'il réserve une certaine quantité de mémoire en RAM afin d'y stocker les informations relative à notre objet.

Lorsqu'une instance n'est plus nécessaire, le programme libère l'espace mémoire précédemment réservée, et détruit notre instance, c'est ce que l'on appelle la libération mémoire.

En pratique

Selon les langages, la gestion de la mémoire est une tâche plus ou moins aisée. Ceux qui bénéficient d'une expérience en C/C++ (ou autre langage bas niveau), connaissent les difficultés liées à la gestion de la mémoire. Jongler entre les pointeurs et les adresses mémoire n'est pas aussi amusant qu'on le voudrait.

Toutefois, la gestion de la mémoire est d'un enjeu critique. Une mauvaise gestion de celle-ci peut entraîner des désagréments allant du simple crash, à la faille de sécurité, en passant par la perte de performance et une myriade de fuites-mémoire. 🤯

C'est pourquoi les langages haut niveau (dont JavaScript fait parti), imposent généralement un système limitant les possibilités du développeur en matière d'allocation mémoire. Adieu malloc, adieu les pointeurs, le garbage collector gère désormais la libération mémoire pour nous. Ainsi nous pouvons concentrer tous nos efforts sur la logique propre à notre application, et non à son fonctionnement subsidiaire.

Enfin, il est toujours bon de rappeler que le garbage collector ne peut ni être invoqué explicitement (comme j'ai parfois entendu certains développeurs le supposer), ni être contrôlé d'une quelconque façon que ce soit. Au mieux, il est possible de diminuer son impact en gérant judicieusement le cycle de vie des instances. C'est justement sur ce point que nous allons jouer.

L'Object Pool Design Pattern et le Javascript

On peut s'interroger sur les bénéfices apportés par l'object pool. En effet, si le garbage collector s'occupe de l'allocation mémoire et de libération mémoire, ce n'est sont plus de notre ressort. Pourquoi s'encombrer avec un tel système ?

Et puis : "Jusque là, mes applications ont toujours bien fonctionnés"

Certes.

Il faut garder à l'esprit que l'allocation mémoire et la libération ne sont pas des opérations anodines. Elles peuvent être relativement coûteuses en fonction du nombre et de la complexité des instances à créer ou à détruire.

Diminuer le coût de fonctionnement de notre application est possible en recyclant nos instances :

Au lieu de laisser le garbage collector les détruire, on conserve une référence de ces instances dans un pool d'instances. Ainsi, elles sont toujours considérées comme actives par le garbage collector, mais temporairement non utilisées au sein de notre programme.

✔️ On aura économisé une libération mémoire.

Lorsqu'une instance du même type sera requise, plutôt d'en créer une nouvelle, on récupèrera l'instance recyclée dans notre pool d'instance.

✔️ On aura économisé une allocation mémoire.

Mise en situation

Exercice : un monde de particules

Supposons que l'on développe le système de particule suivant :

Des particules apparaissent sur un fond noir avec une position et une couleur aléatoire toutes les 200ms. Chaque particule vit approximativement 1000ms. Lorsqu'on déplacera la souris, un nuage de particule suivra le curseur. Pour donner une impression de crépitement, on déplacera les particules à chaque rendu sur des cases voisines.

let particles = [];
const maxTtl = 50;

    class Particle {
        constructor(x, y, r, g, b) {
            this.initialize(x, y, r, g, b);
        }               

        initialize(x, y, r, g, b) {
            this.x = x || 0;
            this.y = y || 0;
            this.ttl = maxTtl;
            this.rgb = [
                r || 255, 
                g || 255, 
                b || 255 
            ];
        }

        live() {
            this.wiggle();
            this.ttl--;
        }

        /**
        * Retourne l'index de notre particule dans une matrice de pixels en fonction de sa position (x, y)
        */
        getOffset() {
            return (Math.ceil(this.y) * image.width + Math.ceil(this.x)) * 4;
        }

        /**
        * @image {ImageData} Matrice de pixels sur lesquels faire le rendu
        */
        draw(image) {
            const offset = this.getOffset();

            // 4 channels : r, g, b, a 
            image.data[offset] = this.rgb[0]; 
            image.data[offset + 1] = this.rgb[1];
            image.data[offset + 2] = this.rgb[2];
            image.data[offset + 3] = 255 * (this.ttl / maxTtl);
        }

        wiggle() {
            this.x += Math.random() * 4 - 2;
            this.y += Math.random() * 4 - 2;
       }

       isAlive() {
           return this.ttl > 0;
       }
}

Et c'est tout pour le comportement d'une particule.

Concernant le système en lui-même, on gérera l'apparition de particules grâce à un intervalle :

function clamp(value) {
    return Math.ceil(Math.max(Math.min(value, 255), 0));
}

function spread(x, y, r, g, b) {
    // On crée une particule à l'emplacement désiré
    particles.push(new Particle(x, y));

    // On ajoute un nuage de particules tout autour pour un meilleur rendu
    for(var i = 0; i < 10; i++) {
        particles.push(
            new Particle(
                x + Math.random() * 10 - 5, 
                y + Math.random() * 10 - 5,
                clamp(r + Math.random() * 10 - 5),
                clamp(g + Math.random() * 10 - 5),
                clamp(b + Math.random() * 10 - 5)
            )
        );
    }
}

// boucle gérant l'apparition aléatoire de particules
setInterval(function() {
    for (let i = 0; i < 1500; ++i) {
        spread(
            // position aléatoire
            Math.ceil(Math.random() * context.width),
            Math.ceil(Math.random() * context.height),

            // couleur aléatoire
            Math.ceil(Math.random() * 255),                        
            Math.ceil(Math.random() * 255),                        
            Math.ceil(Math.random() * 255)    
        );
    }                  
}, 200);

// boucle simulant la "vie" d'une particule
setInterval(function() {
    particles.forEach(function(particle) {
        particle.live();
    });
}, 20);

Concernant la boucle d'animation, elle ne présente pas un intérêt majeur dans cet exemple. Néanmoins, si vous êtes curieux :

function clearImage(image) {
    const nbSample = image.width * image.height;
    const data = image.data;
    for (let i = 0; i < nbSample; i++) {
        const offset = i * 4;
        data[offset] = 0;
        data[offset + 1] = 0;
        data[offset + 2] = 0;
        data[offset + 3] = 0;
    }
}

function animation() {
    let nbParticlesAlive = 0;

    clearImage(image);

    particles.forEach(function(particle) {
        particle.draw(image);

        if (particle.isAlive()) {
            nbParticlesAlive++;
        }
    });

    const nextParticles = new Array(nbParticlesAlive);
    let currentParticleIndex = 0;

    particles.forEach(function(particle) {
        if (particle.isAlive()) {
            nextParticles[currentParticleIndex] = particle;
            currentParticleIndex++;
        }
    });

    // La variable particles fait désormais référence à nextParticle
    // -> le garbage collector pourra supprimer l'ancien tableau (quand ça lui chantera)
    particles = nextParticles;
    context.putImageData(image, 0, 0);

    window.requestAnimationFrame(animation);
}

animation();

Une fois que l'on a implémenté toutes ces méthodes, vient l'heure du test :

En le testant, on s'aperçoit que notre système de particule fonctionne à merveille. Notre animation tourne à 60 FPS. 🏆

L'utilisation de requestAnimationFrame limitant notre fréquence maximale à environ 60 FPS, nous obtenons le meilleur résultat possible. Class.

Après quelques secondes d'euphorie et d'auto-congratulation, on essaie de jouer avec notre script, on augmente le nombre de particules et on diminue leur durée de vie. Tout de suite, le résultat est moins flatteur.

Le nombre de FPS s'effondre. La boucle d'animation est durement touchée, le nombre de wiggles par secondes a lui aussi quasiment été divisé par 2. Pourtant le cycle de vie de nos particules était indépendant de la boucle d'animation, et répondait à un intervalle, comment est-ce possible ?

Notre programme est tellement ralenti que le navigateur "repousse" leur exécution. Pourtant, la durée de vie de nos particules se basant sur un timestamp, une des conséquences directes de ce ralentissement est que les particules se déplaceront moins au cours de leur vie et formeront des sortes de pâtés multicolores.

Comment expliquer cette perte de performance ?

En augmentant le nombre d'instances affichées, on a également augmenté le nombre d'allocations mémoires, et donc la libération mémoire lorsque celles-ci meurent. En diminuant leur durée de vie, on laisse moins de temps au garbage collector pour libérer la mémoire, on augmente sa charge.

Un coup d'oeil sur l'analyseur de performance confortera notre hypothèse.

Implémentation de l'Object Pool design pattern

Puisque c'est ainsi, implémentons un pool de particules et voyons si le pattern tient sa promesse.

class ParticlesPool {
    constructor() {
        this.instances = [];
        this.index = -1;
    }

    getOne(x, y, r, g, b, born_at) {
        let instance = null;
        if (this.index >= 0) {
            instance = this.instances[this.index];
            instance.initialize(x, y, r, g, b, born_at);
            this.index--;
        }

        else {
            instance = new Particle(x, y, r, g, b, born_at);
        }

        return instance;
    }

    recycle(instance) {
        this.instances[this.index + 1] = instance;
        this.index++;
    }
}   


const pool = new ParticlesPool();

Puis on adapte notre code pour l'utiliser. Les modifications seront simplissimes :

Remplacer tous les appels au constructeur de Particle par pool.getOne().
Ajouter un appel à pool.recycle lorsqu'une particule meurt afin d'éviter la fuite mémoire.

// ...

function spread(x, y, r, g, b, born_at) {
    particles.push(pool.getOne(x, y, r, g, b, born_at));
    for(var i = 0; i < window.additionnalSpreadParticles; i++) {
        particles.push(
            pool.getOne(
               // ...
            )
        );
    }
}

 // ...

function animation() {

    // ...

    particles.forEach(function(particle) {
        if (particle.isAlive(currentTime)) {
            particle.draw(image);
            nbParticlesAlive++;
        }

        else {
            pool.recycle(particle);
        }
    });

    // ...
}

Et c'est tout !

On relance notre application :

On constate un gain de 10 FPS ! 🚀

Le nombre de wiggle est lui aussi plus élevé. Quant à la charge du garbage collector, celle-ci devient tout de suite plus acceptable.

Analyse à postériori

On n'atteint pas encore les 60 FPS, certes. Mais, il ne faut pas oublier que le but fondamental de notre application est de faire une animation graphique ! En augmentant le nombre d'objets à dessiner, notre boucle de rendu voit naturellement sa charge augmenter. L'object pool design pattern ne peux rien pour cela.

Des optimisations au niveau de la logique de rendu existent, et feront peut-être l'objet d'un autre article. Quant à la gestion mémoire, on peut encore l'améliorer, notamment lorsqu'on recalcule la liste des particules en vie.

Conclusion

L'implémentation d'un Object Pool design pattern peut avoir un effet bénéfique sur les performances de votre application. En gérant judicieusement la mémoire, vous pouvez augmenter le nombre de ressources manipulables par votre application. Dans notre exemple, augmenter le nombre de particules affichables simultanément, l'a rendue plus résiliente. 💪

Bon à savoir

Correspondance avec les autres langages

Cet article / cours se focalise sur les avantages que peut avoir ce pattern pour le JavaScript. On n'y aborde pas du tout la problématique liée à la fragmentation de la mémoire, qui mérite au moins notre curiosité. Pour en apprendre plus à ce sujet, je vous invite à lire cet excellent article (C++/anglais).

Domaine d'application

Comme nous ne développons pas un système à particules tous les jours, voici d'autres exemples d'utilisations :

Les jeux vidéos : on instancie toute sorte d'objets à durée de vie limitée.
Le traitement d'image et la 3D : pour tout ce qui est calcul, équation mathématique, gestion des ressources.
Couplé à un Singleton, on le retrouve régulièrement comme un service gérant les connections à une couche tierce, cache, connexions base de données, pool de workers, etc.

Ce pattern est particulièrement adapté quand :

Vous devez instancier un grand nombre d'objets complexes.
La durée de vie de ses objets est courte.
Le nombre d'objets requis simultanément est faible.

Le mot de la fin

Voici qui clôt mon premier article (qui prend un peu des aspects de cours) ! 🤓

Je sais qu'il est un peu long, le sujet est tellement dense qu'il mérite bien toutes ces lignes. N'hésitez pas à me faire remonter vos remarques afin d'améliorer la qualité de mes articles !

D'ailleurs, si vous avez déjà rencontrés ce design pattern, ou qu'il vous a sauvé la vie, je vous encourage à partager votre expérience dans les commentaires. 😃

DEV Community: Quentin Philippot

Optimisation des images pour des performances web : techniques et conseils

Dimensionner et compresser ses images

Privilégier les images vectorielles

Images adaptatives et srcset

Formats Next-Gen

Lazy-Loading

La balise img

Intersection Observer

Utiliser une librairie

Gestion du cache navigateur :

Conclusion

Créer des modales avec React

Implémentation d'une modale en React

Utilisation de l'élément<dialog> et useRef

Contrôle de l'état d'ouverture / fermeture de la modale

Fausse bonne idée : gérer l'ouverture via css

Synchroniser le DOM avec le contexte React

Donner du style à sa modale 😎

Amélioration : Bloquer le scroll en arrière-plan

Support de la fonctionnalité "click outside"

Implémentation

Brancher l'écouteur "click-outside" sur l'élément dialog

Augmenter la réutilisabilité avec un custom hook

🛠 Précisions techniques, détails et conseils d'accessibilité

Boîte de dialogue classique

Les "vraies" modales

Conclusion :

Modal vs Dialog : Comprendre les différences

Qu'est-ce qu'une modale ?

Qu'est-ce qu'une boîte de dialogue ?

Différences entre modale et boîte de dialogue

Comportement et accessibilité des boîtes de dialogue

Comportement et accessibilité des modales

Contenu inerte

Gestion de la navigation clavier

Confusion entre modale et dialog

Ce que n'est pas une modale

Une erreur courante

Quels enjeux ?

Conclusion

Appliquez des filtres sur vos vidéos avec Javascript

Appliquez des filtres sur vos vidéos avec Javascript

Comment retoucher des images à la volée ?

Intégrer une vidéo à la page

Récupération du flux vidéo en JS

Manipuler ses pixels avec ImageData

Quelques explications sur la classe ImageData

Afficher une image retouchée dans un <canvas>

Un filtre, oui ; mais aussi une animation !

Synchroniser l'animation avec le lecteur vidéo - Définir la boucle de rendu

Implémentation d'un filtre - Définir une méthode de rendu

Résumé

Résultat préliminaire

Exemple d'implémentation de filtres en JS

Grayscale

Supporter les interactions souris

Déterminer la position de la souris par rapport au canvas

On corse le jeu ! 🚀

Rappel géométrique

Approche générale

Sa vision est basée sur le mouvement ! 🦖

Amélioration simple

La vie en bleu 🦜

Rappel sur la représentation de la couleur

Principe du filtre

Implémentation

Calcul de la LUT

Coup d'oeil sur la méthode de rendu

Conclusion

Faites vos propres animations en JS

L'approche intuitive

La boucle de rendu

Boucle de rendu, méthode de rendu, quelle différence ?

Gérer le cycle de rendu

Limitation des méthodes de rendues reposant sur un intervalle

Intervalles non réguliers et drift

Des problèmes de performances historiques

La méthode window.requestAnimationFrame

Interagir avec une animation

Images adaptatives et `srcset`

Utilisation de l'élément`<dialog>` et `useRef`

Manipuler ses pixels avec `ImageData`

Quelques explications sur la classe `ImageData`

Afficher une image retouchée dans un `<canvas>`