OpenGL
La portabilité
En théorie : OpenGL est cross-plateform
L'une des grandes forces d'OpenGL - et l'une de ses priorités - est sa portabilité dans les systèmes. Contrairement à beaucoup d'API graphique, OpenGL est accessible sur n'importe quel système d'exploitation. Il est possible qu'une même application graphique fonctionne sur deux systèmes d'exploitations différentes grâce à cette API.
OpenGL offre des outils aux développeurs et les encourage à faire évoluer la bibliothèque graphique et à la rendre
utilisable sur un très grand nombre de plateformes.
Cela a permis aux sociétés Sony et Nintendo de développer une version d'OpenGL adapté pour leurs consoles de jeux.
Comme discuté dans la partie "Utilisation", la portabilité d'OpenGL s'étend sur les plateformes mobiles et sur les systèmes embarqués
(grâce à l'API OpenGL ES) et sur le web (avec WebGL).
OpenGL est indépendante du système d'exploitation et du matériel.
En pratique : OpenGL peut rencontrer des difficultés avec la portabilité
Même si OpenGL est l'une des API la plus portable du marché, elle peut néanmoins rencontrer des difficultés dans la pratique.
Difficultés liées à la version de la bibliothèque
Les bibliothèques OpenGL comportent des fichiers natifs (.dll pour Windows, .so pour Linux...), afin que l'API puisse être
utilisé par le système (et le matériel). Ainsi, pour que l'API soit exploitable par un grand nombre de systèmes, les auteurs
doivent publier une version de leurs bibliothèques pour chaque systèmes d'exploitations et pour chaque
architecture du processeur (32/64 bits, intel ou amd...).
Par exemple, pour chaque nouvelle version de la bibliothèque JOGL, les développeurs publient 8 bibliothèques différentes pour chaque
système et chaque processeur.
"La" solution pour résoudre ce problème est d'implémenter toutes les fichiers natifs dans l'application et d'utiliser l'un ou l'autre selon le système.
Difficultés liées à certaines fonctionnalités d'OpenGL
Ce problème est très rare mais existant : Une méthode d'OpenGL peut être comprise différemment selon les systèmes (que ça soit au niveau de l'OS ou du matériel). Par exemple, une transformation de la scène (ou de la matrice) peut avoir un résultat différent entre deux postes.
En outre, certaines fonctionnalités d'OpenGL peuvent ne pas fonctionner entièrement (Exemple : les Vertex Buffer Object). Mais cette situation ne concerne que les postes peu performantes (ou qui ne possèdent pas de matériel graphique adéquate), et il existe des méthodes pour vérifier si le système est capable de supporter la fonctionnalité ou non.
Pour se défendre, l'API OpenGL est construire sur une norme et sur une architecture indépendante du système et du matériel. Alors, OpenGL n'est pas l'origine de ces problèmes, mais "les autres": Les constructeurs des matériels graphiques sont responsables pour maintenir à jour leurs drivers et leurs matériels, selon la norme fixé par OpenGL (s'ils utilisent cette technologie).
Difficultés liées aux extensions
Certaines extensions sont dépendantes d'un système, d'une plateforme, ou d'un matériel.
Par exemple, l'extension qui implémente la technologie Nvidia PhysX ne fonctionne que pour les cartes graphiques
de marque Nvidia (et non ATI).
Les développeurs qui utilisent ces extensions sont bien conscients de ces problèmes qu'ils peuvent rencontrer. Hors, cela
signifie qu'il n'existe pas de règles ou de norme à respecter pour encourager les développeurs à concevoir des
extensions portables. Cependant, faut-il forcer les concepteurs d'une extension ou d'une bibliothèque, dédiée
pour une plateforme ou pour un système spécifique, à rendre leur projet portable sur d'autres systèmes ?
Il est conseillé d'utiliser des extensions lorsque le projet nécessite des fonctionnalités plus avancées. Et si c'est le cas, il faudra faire attention à la portabilité de ces outils (surtout pour les projets multiplateformes).
Ce n'est pas l'API graphique qui fait la portabilité de l'application
Pour rappel, OpenGL est cross-plateform, ce qui signifie que cette technologie peut être utilisée sur n'importe quel système.
Cependant, une bibliothèque graphique ne rend pas le code d'un logiciel portable. En général, c'est le langage de programmation et
son compilateur qui définient si un programme peut être multiplateforme ou non.
Une application graphique codé en C, utilisant l'API OpenGL, compilé sur un Linux 32bits, a peu de chance de fonctionner sur un système Windows 64 bits. Une application graphique développée en Java aura toutes ses chances.