2017-08-01 1 views
0

Je travaille sur le développement d'un artefact logiciel qui utilise fabric.js-1.6.6. Le code sera utilisé par d'autres programmeurs qui pourraient ajouter/supprimer des objets dans le canevas et interagir avec eux. Pour éviter les retards causés par les routines de rafraîchissement des autres programmeurs, j'ai décidé d'implémenter une fonction de rafraîchissement globale transparente pour les utilisateurs de mon code. La routine rafraîchissante ressemble à ceci:Toile fabric.js en permanence rafraîchissante

(function render() { 
     fabric.util.requestAnimFrame(render); 
     canvas.renderAll(); 
    })(); 

Je sais que cela peut être pas super efficace (comme la toile se rafraîchit tout le temps), mais j'empêche d'autres programmeurs d'avoir à faire face à rendre la toile sur leur propre lors de l'implémentation d'objets spécialisés dont l'apparence change de manière permanente et qui nécessite donc la mise à jour du canevas.

Récemment, j'ai essayé de migrer mon code vers fabric 2.0.0 beta 4 mais le canvas n'est plus mis à jour. Des idées pour résoudre le problème?

De même, existe-t-il un moyen plus efficace et plus efficace de disposer d'une routine permanente de rafraîchissement des canevas? Ce que j'ai décidé de faire a été inspiré par la démo de tissu officielle Animating polygon points, mais mon canevas nécessite un nombre significativement plus élevé d'objets qui changent tout le temps, donc ce n'est peut-être pas la meilleure stratégie.

+0

pouvez-vous fournir un violon où l'utilisation de cette fonction ne rend pas le canevas dans le tissu 2.0.0beta4? – AndreaBogazzi

Répondre

0

Ma suggestion personnelle est de commencer à regarder à 2.0.0 La nouvelle version implémenter une nouvelle méthode appelée requestRenderAll qui utilisera correctement requestAnimationFrame. Considérons que le fait d'avoir le canevas de restauration automatique toutes les 16ms peut être une surcharge. Pour moi, la solution la plus élégante consiste à demander à d'autres développeurs d'utiliser requestRenderAll et non renderAll.

L'appel chaîné de requestRenderAll n'aura aucun effet, puisque jusqu'à ce que l'animation soit encore en cours de requête, d'autres ne sont pas demandés.