UGE Paint

Calcul de la taille de la fenêtre

Toutes vos classes pour cet exercice doivent être dans le package fr.uge.poo.paint.ex6. Recopiez vos classes du dernier exercice du TP précédent dans ce nouveau package.

On continue le développement de notre application Paint. On veut maintenant calculer la taille de la fenêtre d'affichage de manière à ce que toutes les figures puissent s'afficher dedans. On veut aussi garantir que la fenêtre ne fera pas moins de 500 de hauteur et moins de 500 de largeur.

Faire évoluer l'application Paint.

Pour tester, vous pouvez utiliser les fichiers draw-small.txt (qui devrait s'afficher dans une fenêtre de 500x500) et draw-big.txt (qui devrait s'afficher dans une fenêtre de 800x800).

Nouvelle librairie graphique

Toutes vos classes pour cet exercice doivent être dans le package fr.uge.poo.paint.ex7. Recopiez vos classes de l'exercice précédent dans ce nouveau package.

Après les premiers succès de votre application Paint, votre compagnie est rachetée par EvilCorp. Cette compagnie a developpé une librairie graphique CoolGraphics.java. D'après la documentation, cette librairie offre une API simplifiée et une jolie bordure rouge.

Familiarisez-vous avec cette nouvelle librairie en regardant le petit exemple de code suivant CoolGraphicsExample.java.

On vous demande de faire en sorte que votre application Paint utilise la nouvelle librairie CoolGraphics par défaut. Cependant si l'utilisateur appelle Paint avec l'option -legacy sur la ligne de commande, votre application devra utiliser la librairie SimpleGraphics. Bien entendu, il est impensable d'avoir deux codes complètement différents pour Paint en fonction de la librairie graphique choisie.

Faire évoluer l'application Paint.

Et la performance dans tout cela ...

Toutes vos classes pour cet exercice doivent être dans le package fr.uge.poo.paint.ex9. Pour simplifier les choses, on va partir du code obtenu à l'exercice 7 (c'est à dire sans le chargement dynamique des jars). Recopiez vos classes de l'exercice 7 dans ce nouveau package.

La librairie SimpleGraphics permet de réaliser plusieurs dessins sans faire de réaffichage grâce à la méthode simpleGraphics.render. On peut ainsi ainsi dessiner 3 lignes et ne faire qu'un seul réaffichage (comme dans le code ci-dessous).

	area.render(graphics -> {
            graphics.drawLine(100, 20, 140, 160);
            graphics.drawLine(100, 160, 140, 20);
            graphics.drawLine(100, 160, 140, 120);
        });

Avec votre adaptateur pour la librairie SimpleGraphics, il est fort probable que, pour dessiner ces 3 lignes, on exécute le code suivant:

area.render(graphics ->graphics.drawLine(100, 20, 140, 160));
area.render(graphics ->graphics.drawLine(100, 160, 140, 20));
area.render(graphics ->graphics.drawLine(100, 160, 140, 120));

Le problème est que chaque appel à la méthode render redessine le contenu de la fenêtre (ce qui peut provoquer des scintillements à l'écran). Ce phénonème est inévitable avec la librairie CoolGraphics car elle n'expose pas la méthode render. On voudrait changer l'interface que nous utilisons pour unifier les deux librairies graphiques de manière à pouvoir (quand on utilisera l'adaptateur de la librairie SimpleGraphics) faire plusieurs dessins avec un seul réaffichage.

Définir une nouvelle interface graphique commune avec des fonctionalités étendues qui permettent cette optimisation et modifier vos adapteurs pour permettre de faire plusieurs dessins puis de les afficher. Adapter le reste de l'application en conséquence.

Attention, la méthode render de SimpleGraphics exécute le code du consumer dans un autre thread. Il faut que vous preniez cela en compte dans votre nouvel adaptateur.