Affichage 2D : pourquoi pas OpenGL ?

Bonjour à tous,

Dans une appli codée en VB.NET, j'ai une fenêtre de visualisation en 2D et une autre en 3D faite avec OpenTK.

Quand je visualise une grosse pièce en 2D, vue de dessus (empilement de polygones en couleurs) l'affichage est lent.
A chaque déplacement de la vue avec la souris il faut redessiner les polygones avec .fillPolygon()

Pièce jointe 368197

Quand je visualise la même pièce en 3D avec OpenTK, c'est beaucoup plus fluide.
Pourtant, à chaque déplacement de la vue avec la souris je dois demander à OpenGL de redessiner tous les triangles (150.000), et OpenGL fait le calcul de l'affichage 3D avec 3 sources lumineuses et pas mal de "raffinements"
D'ailleurs je trouve ça un peu dommage, je n'ai pas compris comment demander à OpenGL de simplement déplacer la scène (ou mon point de vue) sans être obligé de rentrer la liste de tous les triangles à chaque affichage.

Pièce jointe 368200

C'est facile à comprendre, la 3D avec OpenGL utilise l'accélération matérielle, la 2D avec VB.NET c'est les fonctions de System.Drawing...

Dans les deux cas mon code source est optimisé, tous les calculs intermédiaires ou répétitifs sont évités, tout ce qui peut être pré-calculé l'est.

Du coup je me demande si pour la vue en 2D je ne vais pas carrément utiliser OpenGL :aie:

C'est un peu un marteau pour enfoncer une punaise mais OpenGL permet de faire de la 2D aussi (en désactivant DepthTest puis ensuite en ne donnant que des points Vertex2)
Et ce sera super rapide puisque c'est la CG qui va faire le taf

Qu'en pensez-vous ?

Qu'avez vous utilisé pour vos logiciels de dessin ou de visualisation "2D" ?

A bientôt

Bonjour,

Alors je me suis lancé pour utiliser OpenGL pour la 2D

https://www.ntu.edu.sg/home/ehchua/p...roduction.html

(voir aussi la pièce jointe en PDF)

Aspects positifs :
- affichage ultra-rapide
- utilise le GPU et soulage le CPU
- possibilité de faire des dégradés
- possibilité d'utiliser des textures
- OpenGL gère le clipping, les translations, les rotations, le zoom ; la navigation à la souris est plus facile à coder (une seule ligne GL.Ortho() suffit)
- possibilité d'avoir une seule interface permettant d'avoir de la 2D et de la 3D
- le contrôle OpenTK permet de gérer les événements aussi facilement qu'un PictureBox
- OpenGL étant universel, le code est portable

Aspects négatifs :
- gros travail de réécriture du code
- pas de courbes, pas de cercles, pas de polygones complexes, les formes en mode trait doivent êtres décomposées en segments de droites
- les formes pleines doivent êtres décomposées en triangles (c'est parfois difficile, heureusement j'ai déjà résolut ce problème dans mon appli pour la 3D)
- on ne peut pas afficher de texte sauf en "bricolant"

Dommage que l'affichage de texte ne soit pas pris en charge, sinon j'aurais pu faire une partie l'interface de mon logiciel sous OpenGL (un peu comme dans un jeu vidéo)

A bientôt

normalement il y a moyen d'être performant en windows forms, même s'il faut parfois tricher un peu (doublebuffering ou buffering manuel)
je serais curieux de voir ton code pour savoir s'il est réellement optimisé ... parce qu'à priori il n'y a pas grand chose d'affiché non plus
(il faut aussi éviter windows xp)

on peut aussi avoir un rendu plus lissé (avec smooth quelque chose)

Citation:

---

Envoyé par Pol63

normalement il y a moyen d'être performant en windows forms, même s'il faut parfois tricher un peu (doublebuffering ou buffering manuel)
je serais curieux de voir ton code pour savoir s'il est réellement optimisé ... parce qu'à priori il n'y a pas grand chose d'affiché non plus
(il faut aussi éviter windows xp)

on peut aussi avoir un rendu plus lissé (avec smooth quelque chose)

---

J'ai optimisé le code mais sans bidouiller

Les coordonnées "écran" (en pixel) sont précalculées dans des tableaux d'entiers

A chaque affichage, j'utilise les fonctions .DrawPolygon, FillPolygon, DrawEllipse, FillEllipse

Dans le cas d'un déplacement à la souris, les données sont directement passées .DrawXXX et .FillXXX avec seulement une addition (translation)

Ce code n'utilise pas le GPU, que le CPU avec GDI / GDI+

Dans mon programme j'ai une partie 3D avec OpenGL beaucoup plus rapide (et ce n'est - pour l'instant - que de l'OpenGL 1.1 donc "lent", je suis en train de voir pour passer à OpenGL 3)

Pour du dessin de formes géométriques (vectoriel) OpenGL me semble plus convaincant. D'autant que j'ai déjà un code de triangularisation de polygones qui fonctionne très bien, et de toutes façon mon programme ayant un affichage 3D OpenGL autant faire la 2D avec.

Par contre tu me parles de doublebuffering ou buffering manuel et ça m'intéresse.

En effet, dans mon programme il y a une partie ou je dois pouvoir éditer une image BMP (en gros comme MS Paint). C'est clair que je ne ferais pas ça en OpenGL :aie:

Il faudra que ce clône de Paint soit le plus efficace possible :
- edition au niveau du pixel avec un zoom
- quelques fonctions de traitement d'image (filtres, contraste, remplacement de couleur...)

Actuellement je travaille sur des données BMP mais pas en tant qu'image, directement en tant que données binaires (à la lecture du fichier puis sous forme de tableau de byte())

Ce traitement est rapide mais "aveugle".

Dans mon clone de Paint, je devrais à la fois pouvoir afficher les données BMP sous forme d'image et travailler sur les données rapidement (donc pas de GetPixel ni SetPixel :mrgreen: :aie:)

Autre difficulté : le lissage éventuel à l'affichage du BMP ne doit pas affecter les données

A bientôt

https://msdn.microsoft.com/fr-fr/lib...v=vs.110).aspx
https://msdn.microsoft.com/fr-fr/lib...v=vs.110).aspx
(si c'est protected il faut hériter de control)

sinon il y a la classe bufferedgraphics


pour la modification de bmp : https://stackoverflow.com/questions/...ve-to-getpixel

Très intéressant tout ça !

Je me souviens d'un échange sur ce forum où on avait parlé du marshaling, testé avec succès il y a quelques années

Pour résumer, dans mon appli je dois avoir "en double" :
- les données BMP sous forme d'un tableau d'octets ou d'entier (manipulées comme des données "normales")
- un objet graphique pour l'affichage

Dans le code :
- Si un traitement (calcul) se fait sur les données, c'est seulement à la fin du traitement que les données sont envoyées d'un bloc vers l'objet graphique, pour affichage.
- Si un traitement se fait via une fonction GDI / GDI+, à la fin du traitement je récupère les données bitmap de l'objet graphique d'un bloc pour les copier dans mon tableau.
- La navigation à la souris pour l'affichage (translation, zoom) devra se faire sans conversions de données entre le tableau et l'objet graphique
- Pour l'édition à la souris c'est moins critique car à chaque action de la souris le nombre de pixel en cause est limité (tout dépendra évidemment de la nature des fonctions d'éditions dont j'ai besoin, et si elle peuvent êtres faites directement avec les fonctions graphiques ou pas) ; on peut très bien imaginer que la conversion de données graphique -> tableau ne se fasse pas après chaque action "graphique" de la souris mais seulement avant de sauvegarder ou avant de débuter une opération travaillant sur le tableau, c'est facile à gérer avec un drapeau "ModifGraphique"

Avec du code unsafe il y a moyen je pense d'écrire dans le bitmap aussi rapidement que dans le tableau d'octets ; un logiciel de dessin codé en C++ procède certainement ainsi.
Cela évite d'avoir les données "en double" mais on contraint l'ordinateur à verrouiller en permanence l'emplacement en mémoire de l'objet graphique, ce qui va un peu à l'encontre de la philosophie des OS actuels.

Le source (daté d'il y a 9 ans) de Paint.NET sur GitHub est intéressant à ce sujet : https://github.com/rivy/OpenPDN/blob...naryPixelOp.cs

A bientôt

Autre précision :

L'affichage 2D est vraiment très lent dans un de figure où je dois dessiner plusieurs "couches" empilées les unes sur les autres.

Chaque couche est une image avec une couleur transparente (le fond et les trous des polygones), et je ne peux faire autrement que de dessiner chaque couche dans un BitMap, puis de peindre ce BitMap dans le BitMap correspondant au contrôle

Le problème étant que la fonction .FillPolygon ne gère pas les trous !
Donc pour dessiner un polygone avec un ou plusieurs trous :
- 1) il faut dessiner le polygone sans les trous
- 2) puis dessiner à l'intérieur avec la couleur "transparente" chaque trous

Il est impossible de dessiner les polygones de chaque couche avec trous les uns sur les autres car au moment du dessin des polygones (1) on écrase des données là où ensuite seront placés les trous (2)

Si .FillPolygon gérait les trous (on passerait en paramètre le tableau de point du polygone et aussi une liste de tableau de points pour chaque trou) le problème ne se poserait pas.

Cette usage de la transparence implique un deuxième problème que tu as évoqué : l'absence de lissage.

Si je lisse chaque image, la couleur de transparence est "fondue" au niveau des bords des polygones et du coup l'affichage final est incorrect.

Du coup dans ce mode de dessin "multicouche" je ne peux pas lisser l'image.

Voici le code en question :

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

Private ImgXY_g As Graphics Private ImgXY_bm As Bitmap Private ImgXZ_g As Graphics Private ImgXZ_bm As Bitmap   'Préparation : WX = ImgXY.Width WY = ImgXY.Height ImgXY_bm = New Bitmap(WX, WY) ImgXY_bm.MakeTransparent(CouleurTransparent)     'Code d'affichage dans le mode "superposition des couches" ImgXY.Image = ImgXY_bm ImgXY_g = Graphics.FromImage(ImgXY_bm) ImgXY_g.SmoothingMode = Drawing2D.SmoothingMode.AntiAlias ImgXY_g.Clear(CouleurFond)   For i = 0 To ListeCouches.Count - 1 co = ListeCouches.Item(i) ImgXY_bm2 = New Bitmap(WX, WY) ImgXY_g2 = Graphics.FromImage(ImgXY_bm2) 'ImgXY_g2.SmoothingMode = Drawing2D.SmoothingMode.AntiAlias C'est catastrophique avec la transparance ! For k = 0 To co.Liste_Chemins_2D.Count - 1 Ch = co.Liste_Chemins_2D.Item(k) With Ch If .Categ = TypeChemin.ContourInt Then ImgXY_g2.FillPolygon(BrosseTransparent, .Tab_PointE2D) ElseIf .Categ = TypeChemin.ContourExt Then ImgXY_g2.FillPolygon(Brosse(i + 1), .Tab_PointE2D) End If End With Next ImgXY_bm2.MakeTransparent(CouleurTransparent) ImgXY_g.DrawImage(ImgXY_bm2, 0, 0) Next

---

Avec OpenGL en 2D le problème ne se pose pas car les polygones avec trous sont triangularisés et on ne dessine que des triangles.

Je n'ai pas essayé de dessiner directement les triangles avec .FillPolygon mais ça risque d'être super lent car les triangles sont très nombreux ! :aie:

A+

Bonjour,

Je viens de terminer de passer tout mon affichage 2D en OpenGL et je confirme que c'est beaucoup plus rapide que GDI

Pourtant :
- ce n'est que l'OpenGL "ancien" donc avec des Vertex2
- chaque polygone est découpé en de nombreux triangles
- chaque cercle est découpé en de nombreuses lignes
- chaque disque est découpé en de nombreux triangles
- chaque ligne épaisse est faite de triangles
- un ensemble de traits épais avec bout arrondi correspond à pas mal de triangles (deux triangles par segments + pas mal de triangles pour les arrondis) !

Tout ceci est surprenant, pourquoi la GDI est aussi lente ?

Je dois néanmoins rester en GDI pour de l'édition BMP, voyez ce sujet : https://www.developpez.net/forums/d1...giciel-dessin/

A bientôt

gdi date de 1995 (et gdi+ de 98 surement), ca n'utilise pas la carte graphique, alors qu'openGL si

WPF (framework graphique .net plus récent que windows forms) utilise directX (donc la carte graphique)

Citation:

---

Envoyé par Pol63

gdi date de 1995 (et gdi+ de 98 surement), ca n'utilise pas la carte graphique, alors qu'openGL si

WPF (framework graphique .net plus récent que windows forms) utilise directX (donc la carte graphique)

---

Bonjour,

Je croyais que WPF remplaçait seulement Windows Form ; avec WPF on a accès à de nouvelles fonctions graphiques pour dessiner et manipuler des bitmaps ???

Mon programme Open GL est compatible même avec les vieux PC sous windows XP

C'est important car mon logiciel est un CAD, il sert à créer des programmes pour machines outils et beaucoup de PC associées à des machines outils tournent encore sous XP.

J'ai peur que WPF ne fonctionne pas avec les anciennes config...

Pour mon problème de dessin BMP je devrais améliorer les performances avec du Marshalling ? https://www.developpez.net/forums/d1...giciel-dessin/ Je sais bosser sur des données BMP sans passer du tout par les fonctions graphiques via des tableaux, mais là je dois faire les deux.

A bientôt

wpf ne remplace pas windows forms, c'est un nouveau framework (enfin nouveau de 2008)
ca ne ressemble en rien à windows forms, c'est même un peu déroutant au début
et pour tout ce qui est graphisme il y a des nouvelles classes, avec peut etre même moins d'appui sur des api de windows, mais plus sur directX (rien sur gdi en tout cas)
même System.Drawing n'est pas utilisé en wpf

wpf fonctionne sur xp sp3 si tant est qu'on cible le framework 4

windows forms et wpf peuvent être mixés, pour les controles il y a un controle host wpf pour mettre du wpf dans windows forms et réciproquement

Merci pour cette réponse très précise

Assez peu d'ordinateurs "CNC" sous XP ont le SP3

Pour mon appli ; je vais rester avec OpenGL et GDI ; il me reste à optimiser un peu le code GDI pour l'édition et l'affichage de BMP.

J'hésite entre deux façons de faire :

1) : conserver le code actuel, mais via LockBits et autres fonctions du genre travailler plus rapidement

2) : travailler uniquement sur des données tableau et n'utiliser la GDI (ou OpenGL) que pour actualiser l'affichage.
L'affichage ne se fait qu'avec des BMP ARGB 32 bits, alors que je travaille sur des BMP 1 bit, 8 bits ou 24 bits.
Je dois donc trouver le moyen, à chaque affichage, de convertir et d'afficher le plus rapidement possible le rectangle visible de mes données BMP 1 bit, 8 bits ou 24 bits

A bientôt