Discussion :

[Watilin]

Ce que j'ai remarqué, c'est que W3C préconise dans un exemple d'utilisation d'exploiter l'objet DOM img via la méthode document.getElementById... :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Code récupéré sur w3schools
…

Attention, W3Schools n’a rien à voir avec le W3C, comme indiqué sur leur page d’à propos. Et ce site à tendance à ne pas suivre l’évolution des technos (voir W3Fools), aussi je te conseille d’utiliser plutôt le MDN.

[yotta]

C'est noté Watilin, merci pour cette précision, je m'en suis rendu compte hier soir.

[NoSmoking]

@yotta concerne le post #20,
j'ai un peu de mal à comprendre les conditions mises en place dans ta fonction !!

[yotta]

En fait, je cherche à déterminer si o est pair ou impair afin de positionner l'image en haut (yh) quand c'est pair, ou en bas (yb) quand c'est impair dans le cas de la représentation du cursus professionnel.
Pour le cursus scolaire, j'ai pu me permettre de les mettre tous sur la même ligne sans qu'ils se chevauchent (yh = yb), mais pas pour le cursus professionnel ce n'était pas possible, je ne pouvais pas aligner des logos si près les uns des autres, alors j'ai décidé d'en mettre un en haut, et le suivant en bas.
Comme j'utilise exactement le même script pour organiser ces deux éléments que sont mes parcours scolaire et professionnel j'ai intégré un paramètre booléen dans le 'constructeur' d'experience.js si je peux me permettre de l'appeler comme ça. Lorsque etat est vrai, cela signifie que l'on représente le parcours professionnel, sinon le parcours scolaire.
Mon code en est à ses début, il n'est pas encore nettoyé et mérite d'ailleurs d'être réorganisé maintenant si je veux aller plus loin sans produire une usine à gaz abominable.

[Watilin]

Il te faut un modulo, ou un ET binaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// modulo
o % 2 === 0 // o est pair
o % 2 === 1 // o est impair
 
// ET binaire
o & 1 === 0 // o est pair
o & 1 === 1 // o est impair

Au niveau des performances, je n’ai pas vérifié mais ces deux méthodes doivent être au coude à coude. C’est selon ta préférence.

[yotta]

Merci pour ces précisions Watilin. Je connais la fonction modulo, mais je n'en connaissais pas la syntaxe en javascript et parce que je suis un grand fainéant, j'ai eu l'idée de conditionner comme ça. Il est bien évident qu'il est préférable d'utiliser le modulo et comme maintenant je connais la syntaxe, je ne vais pas me gêner.
Cependant, un petit truc m'intrigue ?
Je connais '=', opérateur d'affectation, je connais '==' égalité stricte, mais je ne connais pas '===' ???
C'est spécifique à javascript ou s'agit-il d'une déclinaison de cet opérateur que je ne connais pas ?

[Watilin]

JavaScript, PHP, et sans doute d’autres langages. C’est l’opérateur de comparaison stricte. Il ne fait pas de conversion de type implicite. En général il est recommandé par rapport à l’opérateur == qui est la comparaison « laxiste », car les conversions de types implicites ont parfois un comportement surprenant, d’autant plus que les règles ne sont pas les mêmes d’un langage à l’autre.

[Loralina]

Bonjour,
Il est probable que si le strict avait été le double égal et le non-strict le triple, la plupart des gens utiliseraient en priorité le strict.
En php, il y a pas mal de fonctions, comme "strpos", dont le retour doit être comparé à "false" en strict.

yotta, au niveau du code, un seul "onload" et un seul "Math.round" (pour le calcul du x) devraient suffire, sans oublier d'utiliser "this", conseil donné ici :
https://www.developpez.net/forums/d1...r/#post9035854

[yotta]

Bonsoir Loralina,
Cette ligne est un résidu que j'ai oublié d'enlever et qui ne sert effectivement à rien. Merci, je l'avais oubliée, je l'ai supprimée.
Voilà le code final de ma boucle de dessin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
	for (var i = 0 ; i < logos.length ; i++) {
		(function(o) {
			ImagesLogos[o] = document.createElement('img');
			ImagesLogos[o].id = "Img" + o;
			if (o % 2 === 0) ImagesLogos[o].onload = function() {
				ctx2.drawImage(this, positions[o] + Math.round((positions[o+1]-positions[o])/2) - (largImg/2), yh, largImg, hautImg);
				}
			else ImagesLogos[o].onload = function() {
				ctx2.drawImage(this, positions[o] + Math.round((positions[o+1]-positions[o])/2) - (largImg/2), yb, largImg, hautImg);
				}
			ImagesLogos[o].src = logos[o];
			}(i))
		}

Pour ce qui est du 'this', j'avoue avoir un peu de mal. Si je comprends bien, je peux l'employer parce que le onload s'applique à ImagesLogos[o], donc dans le contexte du bloc de code de onload, this représente ImagesLogos[o] ?

[Loralina]

Bonjour,
Oui pour "this".

Pour l'arrondi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Math.round((positions[o]+positions[o+1]-largImg)/2)

Pour avoir un seul "onload", une possibilité, parmi d'autres, est de faire le test dans la fonction, exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ImagesLogos[o].onload = function() {ctx2.drawImage(this, Math.round((positions[o]+positions[o+1]-largImg)/2), o%2===0?yh:yb, largImg, hautImg);};

Je reviens sur ceci :

Il te faut un modulo, ou un ET binaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// modulo
o % 2 === 0 // o est pair
o % 2 === 1 // o est impair
 
// ET binaire
o & 1 === 0 // o est pair
o & 1 === 1 // o est impair

Au niveau des performances, je n’ai pas vérifié mais ces deux méthodes doivent être au coude à coude. C’est selon ta préférence.

% étant réputé assez coûteux en AS3, j'ai voulu vérifier.

Au préalable, une précision : contrairement au %, pour le &, les parenthèses sont impératives à l'utilisation concrète :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if((i&1)===0)

https://developer.mozilla.org/fr/doc...p%C3%A9rateurs

Ensuite, d'abord en AS3, avec une variable typée "int", les tests sont cohérents et constants, & serait 25 à 50 fois plus rapide que % pour cette comparaison (en retirant la durée du test de la boucle à vide), c'est difficile d'être plus précis sur l'ordre de grandeur tellement le & passe vite.

En javascript, j'ai essayé avec "console.time" sur Firefox, il n'est pas simple d'être précis.
La simple déclaration d'une variable "j", non utilisée ensuite, affecte grandement les tests :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<script>
/*(function()
	{
	var i;
//	var j;
 
	i=100000000;
	console.time("test");
//	while(--i>=0) {} //65 ms
//	while(--i>=0) {if(true){}} //65 ms
//	while(--i>=0) {if(i===0){}} //95 ms
//	while(--i>=0) {if(i%2===0){}} //365 ms si présence d'une simple déclaration d'une variable j, sinon 105 ms
//	while(--i>=0) {if((i&1)===0){}} //même résultat
//	while(--i>=0) {if(i%2===1){}} //même résultat
//	while(--i>=0) {if((i&1)===1){}} //même résultat
	console.timeEnd("test");
	})();*/
 
/*(function()
	{
	var i;
//	var j;
 
	i=-1;
	console.time("test");
//	while(++i<100000000) {} //65 ms
//	while(++i<100000000) {if(true){}} //65 ms
//	while(++i<100000000) {if(i===0){}} //95 ms
//	while(++i<100000000) {if(i%2===0){}} //165 ms si présence d'une simple déclaration d'une variable j, sinon 425 ms
//	while(++i<100000000) {if((i&1)===0){}} //365 ms si présence d'une simple déclaration d'une variable j, sinon 110 ms
//	while(++i<100000000) {if(i%2===1){}} //425 ms, j ou non
//	while(++i<100000000) {if((i&1)===1){}} //365 ms, j ou non
	console.timeEnd("test");
	})();*/
</script>

J'ai testé aussi avec "setInterval", il y a parfois de grandes variations, du simple au double.
Malgré tout, & et % semblent proches (du moins dans cette application bien précise).

[Watilin]

Au préalable, une précision : contrairement au %, pour le &, les parenthèses sont impératives à l'utilisation concrète :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if((i&1)===0)

https://developer.mozilla.org/fr/doc...p%C3%A9rateurs

Ah mince ! En effet. C’est contre-intuitif, le & est une opération arithmétique au même titre que +, elle devrait être prioritaire devant les opérateurs d’égalité. Ok, dans le doute, parenthèses partout…

Ça me rappelle ce piège de PHP où && et AND n’ont pas la même précédence.

Sinon pour la relative lenteur du modulo, je n’étais pas au courant non plus. J’imagine que c’est normal dans la mesure où tous les nombres en JS sont des flottants à double précision, et où le modulo fait intervenir une division. Du coup c’est une opération flottante et c’est forcément plus lent. Mais si on s’en tient à des nombres entiers, ce qui est courant quand on a besoin du modulo, on gagne déjà en performance.
J’ai lu récemment que l’optimisateur de V8 (le moteur JavaScript de Chrome et Node.JS) détectait les cas où un nombre est entier quand il est issu de certaines opérations comme parseInt ou encore les opérations binaires. Du coup on peut considérer que les nombres ont en réalité des « types cachés » qui peuvent être forcés en utilisant une syntaxe un peu émergente :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var n = fonctionQuiRenvoieUnNombre() | 0;

C’est la syntaxe utilisée dans asm.js.

Malgré tout, & et % semblent proches (du moins dans cette application bien précise).

Ils sont proches dans cette application précise car on travaille avec une puissance de 2 (en l’occurence, 2 lui-même). Dans ce cas le modulo est directement « câblé » sur le & binaire.

[yotta]

C'est intéressant ce que vous dites. Vous semblez pointus sur le sujet. Ce n'est pas du tout mon cas, je ne cherche pas tant de précisions.
Cependant, je serai curieux d'avoir une comparaison entre le délai des tests par modulo, et mon astuce à deux balles ((Math.round(o/2) * 2) == o)....
Je vais essayer de mesurer cela

[yotta]

J'aurai besoin d'un petit coup de main. Je ne trouve pas de solution pour mesurer quelque chose qui dure moins d'une milliseconde ?!....

[yotta]

Ok, je viens de comprendre comment faire les mesures, et je note effectivement une différence significative entre l'utilisation de la fonction modulo, et mon astuce à deux balles. Mais je m'attendais à un ration d'au moins 10, en fait, mon astuce à deux balles n'est que 3 à 4 fois plus lente que la fonction modulo, et on reste dans des valeurs raisonnables. Pour autant, je vais maintenir l'usage de la fonction modulo parce que c'est plus performant et plus propre.
Pour tout le reste, encore merci à vous deux.
Bonne continuation.