Discussion :

[lemacdupc33]

Bonjour

Y a t il le plus souvent dans un logiciel une partie graphique autre que des boutons, label, menu deroulant ? Comme des graphiques, des images, des représentations, ou autre...
Dans ce cas utilise t on le plus souvent des points, et un repère ou des formes pour les representer ?

Merci de votre reponse

Cordialement

[tchize_]

Bonjour

Y a t il le plus souvent dans un logiciel une partie graphique autre que des boutons, label, menu deroulant ?

Bah comme tu le dit, des graphiques, des images. Mais aussi parfois des videos, des composants personalisés,....

Dans ce cas utilise t on le plus souvent des points, et un repère ou des formes pour les representer ?

Tu peux élaborer, je n'ai pas compris ta question là.

[lemacdupc33]

Bonjour,

Pour représenter des composants personalisés, des graphiques ou des images, faut il utiliser des coordonnées de points dans des repères et la bibliotheque pour tracer des lignes, des polygones, des rectangles etc .. ?

Merci de votre reponse

Cordialement

[tchize_]

des composants personalisés => on part en général d'un composant existant qu'on personalise. Si tu veux un composant entièrement custom, il faut partir d'un JComponent et te documenter sur comment intégrer ça correctement avec le UIManager. C'est toute une littérature

des graphiques => tu trouvera une foule de librairies en ligne pour faire des graphiques en swing


ou des images => ImageIcon

faut il utiliser des coordonnées de points dans des repères et la bibliotheque pour tracer des lignes, des polygones, des rectangles etc .. => Le paintComponent reçois en paramètre un Graphics, que tu peux caster en Graphics2D et qui contient toutes les primitives. Alternativement tu peux dessiner sur le Graphics associé à un BufferedImage pour ne dessiner qu'une seule fois.

[bouye]

Ça dépend de la lib et de la technologie, si elle est plus ou moins récente, etc.
En parlant de ce qui est fourni de base (différent de ce que l'utilisateur peut être amener a coder comme nouveau contrôle/composant) :

• AWT/Swing/Java2D, principalement des bitmaps** (mais pas toujours, on peut aussi dessiner des formes dans les Graphics). Généralement dans ce setup tu vas dessiner de manière passive dans un contexte graphique (qui peut représenter l’écran, une imprimante ou encore un fichier PDF) qu'on te fourni (la méthode paint() ou paintComponent() n'est pas invoquée par toi mais par le repaint manager).
• JavaFX*, principalement des formes vectorielles (mais on peut aussi utiliser des bitmaps). Ici tu manipules activement un DOM ou encore un SceneGraph, une arborescence de nœuds graphiques pour ajouter/retirer/modifier des nœuds. Une modif de l'arborescence va induire automatiquement une modification de l'affichage en réponse. Hors cas bien particulier (Canvas qui permet justement de faire du dessin bitmap) tu ne manipules jamais aucune primitive de dessin dans un contexte graphique.

*Et aussi pour sortir du monde Java, Flash ou Silverlight, WPF sous Windows ? Mais je peux faire erreur.

Pour le reste tu as plusieurs couches dans une lib graphique / un pipeline de rendu graphique : la couche développeur (a laquelle tu as accès), le moteur de rendu (AKA le repaint manager) et dans tous les cas en bout de pipeline graphique, il y a de toutes manières un rasteriser qui va convertir les formes vectorielles en formes bitmap pour leur affichage sur des périphériques ne supportant que le bitmap (ex: pratiquement tous les écrans standard modernes, les cartes vidéo modernes spécialisées dans la gestion de textures) en fonction du modèle de couleur, du DPI de l'affichage, mais aussi du type de sortie (ex: quand on imprime), etc. .

Disons qu'en AWT/Swing/Java2D, ce rasteriser est beaucoup moins profond dans la pile de traitement et est presque directement manipulable par le programmeur lorsqu'il dessine dans le Graphics. Si mes souvenirs son bons, suivant l’implémentation/l'OS, certaines directives vectorielles de dessin (ex: drawLine()) dans un Graphics peuvent directement se traduire en commande vectorielle équivalente dans la lib native sous-jacente (sous Windows il y a longtemps DirectDraw et plus récemment Direct3D je crois, sous les autres autres GTK, OpenGL, etc.).

JavaFX étant plus abstrait, le SceneGraph c'est pratiquement du vectoriel pur qui est manipule par le développeur. En plus le SceneGraph manipulé par le développeur n'est pas vraiment celui qui est affiché a l’écran. La lib de rendu interne utilise en effet, une seconde arborescence privée de nœuds a sa sauce (comprendre : j'ai aucune idée de comment ils sont implémentés car je n'ai pas été lire les sources) et les modifs d'un arbre sont synchronisées sur l'autre a chaque pulse d'affichage (JavaFX tourne a 60 FPS). Mais mais bien le moteur de rendu sous-jacent va quand même utiliser un rasteriser a la fin et invoquer la lib native d'affichage. Même chose, il peut être amené a invoquer des primitives natifs vectorielles exactement comme AWT/Swing/Java2D.

EDIT - et pour finir les menus sont un cas un peu a part dans JavaFX, ils sont une abstraction supplémentaire, ce ne sont pas des nœuds et ne font pas partie du SceneGraph. En effet la lib peut choisir de les afficher soit de manière software en JavaFX, soit de manière native en fonction de l'OS/la plateforme sous-jacente (ex: les menus générés par la lib sont clairement des nœuds utilisant des popup sous Windows mais sont natifs sous macOS si on active la barre système, sinon ils sont en software)

EDIT 2 - **Jusqu’à l’implémentation du LnF Nimbus pour Swing. La documentation de Sun/Oracle indique que Nimbus est vectoriel contrairement aux autres LnF (crossplatform, system). Par contre ça reste du vectoriel a la Java2D (passif et via l'appel de directives de dessins qui sont sans doute assez vite rasterisées). Concernant le LnF system de Swing (qui permet d'avoir une apparence Windows sur Windows par exemple) dans mes souvenirs d'il y a longtemps il me semble avoir lu un des devs mentionner qu'ils requéraient via des appels natifs des éléments d'UI (bitmap sans doute. MFC pour Windows ?) qui étaient ensuite réutilisés pour décorer l'UI.