Implémentation d'un éditeur d'image côté client - quel est le meilleur moyen?

Question

Nous voulons une application web qui permet à un utilisateur d'éditer des images sur le navigateur et nous essayons de décider quelle technologie utiliser. Nous souhaitons prendre en charge la personnalisation simple des images, comme le redimensionnement, le recadrage, la fusion d'images et les transformations de couleurs de haute qualité, ainsi que l'ajout d'éléments de texte avec différentes polices et couleurs.

Les options sont:

1. flash: pas de soucis sur la compatibilité multi-navigateurs; pourrait utiliser la même bibliothèque d'images sur le client et le serveur; pas de support iPhone/iPad.
2. Java (compilé en javascript avec GWT): besoin de trouver une bonne bibliothèque d'images en Java pur pour pouvoir le compiler en JS.
3. Plain old javascript + HTML5: peut être un désordre dû à plusieurs navigateurs; peut avoir besoin d'écrire le code d'édition d'image à partir de zéro.

Voici ce que nous est le plus important à/critères de choix:

• cohérence de l'image: l'image que le client édite le navigateur doit être exactement le même que celui que nous finirons par utiliser sur le backend. Nous pouvons y parvenir en (a) avoir la même bibliothèque sur le client et le serveur pour traiter les images, (b) avoir le client générer l'image et la télécharger sur le serveur, ou (c) utiliser deux bibliothèques de traitement d'images différentes sur le client/serveur et espérons le meilleur en termes de cohérence. L'option (a) semble la meilleure, mais cela ne serait possible que si nous utilisons Flash ou Java/GWT. Nous n'aimons pas l'option (b) parce que les images sont grandes; nous préférons enregistrer une séquence d'opérations à effectuer sur une image brute plutôt que d'enregistrer plusieurs images transformées. Et nous ne savons pas vraiment si l'option (c) est sûre ou non. Évolutivité: Nous préférons que le client fasse le plus de travail possible pour diminuer la charge du serveur. Multiplateforme: Nous aimerions prendre en charge autant de plates-formes que possible sans tout réécrire (grand négatif pour Flash dû aux iPhone/iPads).

Quel chemin recommandez-vous? Y a-t-il une alternative qui nous manque?

Merci pour toute aide!

Answer 1

Certainement Flash. Si vous allez avec JavaScript et HTML5, vous dites essentiellement "vissez-vous" à tous les utilisateurs d'IE.Le moteur de rendu de Flash est plus rapide pour ces choses que le navigateur, et la vitesse serait constante dans tous les navigateurs. De plus, Flash possède des librairies de manipulation d'images très puissantes, alors qu'en JavaScript, vous devez les écrire vous-même.

Edit: Parce que je viens de recevoir un downvote sur une réponse âgée de 3 ans, je suis obligé de dire que ce n'est plus vrai, et vous devez utiliser les standards du Web comme <canvas> parce qu'ils sont à peu près omniprésentes ces jours-ci. N'utilisez pas Flash.

Answer 2

Nous sommes allés avec 3 parce que les applets Java sont morts et nous n'aimons pas Flash. Le HTML5 est, espérons-le, le futur.
GWT semble être une option intéressante, mais nous ne pouvions pas l'utiliser car le côté serveur est .NET. L'écriture de code d'édition d'image est amusant :)

Answer 3

Je choisirais JS + HTML5 \ canvas. Si vous êtes juste au début de l'écriture de cette application et qu'il n'y a aucune dépendance à la technologie, c'est le meilleur choix. Les navigateurs s'améliorent rapidement contrairement au plugin Flash ou Java (40 à 60% des ordinateurs de bureau l'ont?). Le seul monstre effrayant qui détient la révolution est IE, mais je pense que IE9 nous amènera à la nouvelle ère, où nous pouvons faire des applications cross-browser vraiment cool sur le web en utilisant de nouvelles normes :) Donc, vous pouvez commencer maintenant, et 2 -3 mois plus tard IE9 viendra avec un support de toile et tout ce truc de fantaisie. Tous les autres navigateurs sont prêts en ce moment, mais ils vont évoluer et améliorer la vitesse du moteur JS. J'espère :)