Citation :Ok, au regard de la difficulté (simple regexp), c'est rentable, mais après, de là à jouer l'obfuscation gratuite
Cela portait plutôt sur l'idée de raccourcis les noms pour les rendre obscurs (v pour verticle, t pour triangle, ah oui, mais j'ai aussi texture... bon ben texture, ca sera t2...)
Pour une regexp, là, admettons (mais encore faut-il que cela ne soit pas une charge trop lourde pour le serveur)
A priori l'idée était de gratter sur les nombres flottants. Après, si on souhaite abréger les clés, pourquoi pas, mais autant le faire en utilisant des abréviations évocatrices (en virant les voyelles, par exemple : vrtcl, trngl, txtr).
Je suis plutôt contre les abbréviations car si on fait un break sur le projet, on perdra du temps à les comprendre. Et vu le gain d'octets occasionné... Ca vaut aps trop le coup. Après, remplacer "coordonnee_1" par "x", "coordonnee_2" par "y", là, ok.
Sinon, il faudrait intégrer la description des abbréviations dans un document intégré au JSON/XML (pourquoi pas dans un commentaire XML par exemple), ou linker le XML avec un document xsld décrivant clairement chaque abbréviation.
Bref, d'expérience, je sais qu'obfusquer les noms de variable est généralement contre-productif sur le long terme (et en plus, c'est un travail humain que de relire ses abréaviations, alors que télécharger le fichier est un travail machine, en d'autres mots, au lieu de laisser la machine faire plus de travail, on force l'humain à réfléchir, et donc à perdre un temps qui pourrait être accordé à des tâches plus intéressantes et non-traitables par la machine, comme trouver des idées "marketing" pour distinguer son projet web de la masse des sites existants sur la planète).
Mais je m'égare du sujet, alors, j'en resterai là
Ah mais je suis entièrement d'accord. Autant, arrondir les valeurs ne me semble pas complètement dénué d'intérêt, autant je ne trouve pas pertinent d'abréger des clés.
En fait, faudrait aussi vérifier si javascript prends autant de décimales en compte. Si ce n'est pas le cas, peut etre que javascript doit arrondir ces valeurs et le temps de chargement ne sera que plus long et plus gourmand en ressources (Ce n'est qu'une supposition). J'avais lu un article sur l'optimisation comme quoi il fallait limiter le plus possible les accès au DOM toussa. Et il me semble qu'il etait précisé que Math.round etait particulièrement long a executer. M'enfin a verifier.
Ensuite, Xenos, pour un modèle, je suis d'accord avec toi, ce n'est pas 400ko qui va jouer. Mais je ne compte pas en mettre qu'un seul, mettons avec une dizaine de modèles ce serait 4Mo en moins, et quand tu es en 512k (qui existe encore), ca te fais une minute a attendre.
Je pense que l'optimisation du script ainsi que du poids des ressources est une chose importante. Meme pour les textures on peut souvent diviser par 2 leur poids quasiment sans pertes de qualité.
Qui c'est qui avait dit "optimiser trop tôt, c'est le mal"? (je suis pas certain de ma traduction)...
Donald Knuth a écrit :We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Mais ici, ce n'est pas vraiment approprié dans la mesure où ça ne va de toute façon pas impacter sur la conception de son code.
De toute façon, le problème initial est traité : il sait maintenant comment traiter ses fichiers pour réduire la précision des nombres (et ainsi réduire considérablement le volume des fichiers). Que ça se fasse via la fonction de recherche et remplacement de son éditeur ou autrement (par un simple script en ligne de commande), peu importe.
Ensuite, le débat sur le choix de le faire ou non est un autre problème.
Dans la mesure où ça n'aura aucun impact sur quoi que ce soit d'autre que le poids de ses fichiers, pourquoi se priver ?
(27-01-2013, 02:08 PM)Aleskweb a écrit : [ -> ]Et il me semble qu'il etait précisé que Math.round etait particulièrement long a executer. M'enfin a verifier
Oui, si tu as beaucoup d'arrondis à faire fais plutôt nombre + 0.5 << 0
Sinon ton problème est simple. Pourquoi faire un script dans un autre langage ? Tu as du JSON, tu utilises Three.js donc tu dois pouvoir faire ça en une ligne de JS
for (var i = 0; i < obj.vertices.length; ++i) {
obj.vertices[i] = obj.vertices[i] + 0.5 << 0;
}
Merci Spehi ^^
Oui, le problème est résolu, oui, ca n'impact pas la conception, donc, ok, j'ai pas d'objection à ce niveau là.
T'as pas un soucis de parenthèsage? Il me semble que l'opérateur << est plus fort que l'opérateur +.
D'ailleurs... En quoi "(float +0.5) << 0" ferait-il un arrondis? O.o