Optimisation d'un zoom sur un objet Graphics

Version imprimable

17/02/2014, 13h34
Blangel

Optimisation d'un zoom sur un objet Graphics

Bonjour à tous, je viens ici pour une question d'optimisation. En effet mon code fonctionne mais d'une manière qui ne me plait pas et je pense qu'il y a bien moyen d'optimiser cela, mais je ne trouve pas. Voila mon problème :

Dans mon programme, j'ai un JPanel qui contient un objet d'une de mes classe. Cette classe hérite de MouseListener et MouseMotionListener, il contient donc toutes les méthodes associés en particulier PaintComponent. Les objets de cette classe me permettent ( entre autre ) de tracer des graphes éditable à la souris ( on peut déplacer les sommets, cliquer dessus pour effectuer des actions, ect ...).
J'ai récemment voulu implémenter une fonction permettant de zoomer / dezoomer la vue des graphes. Pour cela j'ai donc créé un attribut "scale" j'ai donc dans la fonction PaintComponent(Graphics g ) :

Code:

g2.scale(scale, scale);

Cela fonctionne donc bien pour l'affichage, mais pour qu'ensuite mes action à la souris soit bien interprété il a fallu que je remplace tout les

Code:

me.getX()

par

Code:

me.getX() / scale

( idem pour Y, me etant un objet de type MouseEvent ).

Comme je l'ai dit en intro, cela fonctionne mais ne me plait pas vraiment ... si quelqu'un a une idée pour optimiser cela, je suis preneur de toutes les pistes de recherche !
Sinon, si c'est le seul moyen, au niveau du temps d’exécution est il plus rapide de faire une division par 1 ou une comparaison avec 1 ( sachant que ce 1 ne sera pas codé en dur dans le code mais sera une variable) ? ( je n'ai jamais eu de cours de java, je ne sais pas vraiment comment il est compilé ensuite et les optimisation que fait le compilateur ).

Le seul moyen j'en sais rien. Mais si tu le fait toi même je ne vois pas comment tu pourrais faire autrement qu'un recalcule des X,Y et prenant en compte le scale et d'éventuel translation. Donc de coder 2 fonction qui te transforme les coordonnée physique de la souris dans la panel en coordonée virtuelle dans le panel et vice versa.

Dans le genre :

Code:

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
36
37
38
39
40
41
42
/*
	 * Transforme la coordonée en bonne coordonnée (avec zoom et translation)
	 */
	public Point2D.Double convertViewXYtoRealXY(double X, double Y)
	{
		double x = X;
		double y = Y;
 
 
		if (BYPASS_ZOOMX == false)			x /= this.ZOOM_X;
		if (BYPASS_ZOOMY == false)			y /= this.ZOOM_Y;
		if (BYPASS_ZOOMX == false)			x /= this.FACTEUR_PRECISION;
		if (BYPASS_ZOOMY == false)			y /= this.FACTEUR_PRECISION;
 
		x -= this.TransX;
		y -= this.TransY;
 
		Point2D.Double p = new Point2D.Double(x, y);
 
		return p;
	}
 
	/*
	 * Transforme la coordonée en bonne coordonnée (avec zoom et translation)
	 */
	public Point2D.Double convertRealXYToViewXY(double X, double Y)
	{
		double x = X;
		double y = Y;
 
		// Facteur pour mettre le dessin centré 
		x += this.TransX;
		y += this.TransY;
 
		if (BYPASS_ZOOMX == false)			x *= this.FACTEUR_PRECISION;
		if (BYPASS_ZOOMY == false)			y *= this.FACTEUR_PRECISION;
		if (BYPASS_ZOOMX == false)			x *= this.ZOOM_X;
		if (BYPASS_ZOOMY == false)			y *= this.ZOOM_Y;
 
		Point2D.Double p = new Point2D.Double(x, y);
		return p;
	}

Après pour ton histoire de division par 1 et comparaison par 1 j'ai rien compris :)

25/02/2014, 17h11
joel.drigo

Citation:

Envoyé par Blangel

Comme je l'ai dit en intro, cela fonctionne mais ne me plait pas vraiment ... si quelqu'un a une idée pour optimiser cela, je suis preneur de toutes les pistes de recherche !
Sinon, si c'est le seul moyen, au niveau du temps d’exécution est il plus rapide de faire une division par 1 ou une comparaison avec 1 ( sachant que ce 1 ne sera pas codé en dur dans le code mais sera une variable) ? ( je n'ai jamais eu de cours de java, je ne sais pas vraiment comment il est compilé ensuite et les optimisation que fait le compilateur ).

Salut,

Tu peux utiliser la transformation affine inverse (de celle que tu utilises pour ton zoom) pour convertir les coordonnées de la souris, plutôt qu'une division. C'est un peu plus propre, mais, à moins que tu aies vraiment des graphes très complexes, les différences sur les performances ne devraient pas être très importantes.

J’utilise dans mon application une bibliothèque de ZUI fondée sur ce principe, pour afficher un ensemble de près de 10000 nodes (avec des paths complexes et des images, et animation, etc...), à plusieurs niveaux (stack) de transformations affines (Certes la bibliothèque intègre quelques points d'optimisation, par clipping en particulier). Et ce n'est vraiment pas sur l'UI que j'ai besoin de travailler l'aspect performance.
25/02/2014, 19h38
tchize_

comme le dit joel, tu peux utiliser un AffineTransform pour faire le zoom et utiliser la matrice inverse pour calculer les x/y en fonction de la souris. Mais cela n'a d'intérêt que si tu effectue des opération plus complexes qu'un simple zoom: combinaison de translation, rotation, scale, ...
25/02/2014, 21h01
Blangel

Ok, merci pour vos réponse. Donc pour l'instant je vais rester comme ça ( de toute façon je n'ai encore jamais vu mon application avoir besoins de réfléchir, mais je préfère partir sur une base propre )

Citation:

Envoyé par wax78

Après pour ton histoire de division par 1 et comparaison par 1 j'ai rien compris :)

En fait je posais cette question car la plupart du temps mon facteur de zoom sera égal à 1, donc je voulais savoir si il valait mieux faire un test du genre "si scale différent de 1 je divise par scale, sinon je fais rien" ou alors tout le temps diviser par scale.
25/02/2014, 21h51
wax78

Je comprends mieux, malheureusement je n'ai pas la réponse, il faudrait benchmarké ca :)
26/02/2014, 08h42
tchize_

Tu n'a pas non plus 10.000 évènements souris par seconde hein, donc non, cette division ne se verra pas.