Ce que je sais c'est que pour y arriver, il faudrait que cette évolution brise la compatibilité avec ses ancêtres ce que le Khronos se refuse à faire.
Encore une fois, c'est faux. Depuis OpenGL 3, de nombreuses parties de l'ancienne API ont été marquées obsolètes. Il suffit d'utiliser le profil forward compatible context pour avoir une API propre, qui casse la compatibilité avec tout ce qui a été écrit pour OpenGL 2. Et jusqu'à présent, chaque nouvelle version a continué d'avancer dans la bonne direction, en phase avec la réalité du matériel moderne.
La seule différence avec un changement brutal (qui était prévu et connu sous le nom de code Long Peaks), c'est que l'on est pas obligé d'utiliser ce profil; en fait le programmeur peut choisir à quel niveau de compatibilité il se place. C'est une contrainte pour les développeurs de drivers, mais absolument pas pour ceux qui utilisent l'API.
Par contre cela laisse la tentation d'utiliser quand même les fonctions obsolètes, là où un changement brutal aurait poussé plus rapidement les développeurs à améliorer leur code.
Quand au problème du design by committee, les coups de gueule poussés à la sortie d'OpenGL 3 ont largement assainit la situation (il suffit de voir le rythme et la qualité des sorties de nouvelles versions depuis).
[^] # Re: L'évolution d'OpenGL est toujours d'actualité.
Posté par drakmaniso . En réponse au journal Mesa, Gallium et D3D10/11 sont dans un bateau. Évalué à 4.
Encore une fois, c'est faux. Depuis OpenGL 3, de nombreuses parties de l'ancienne API ont été marquées obsolètes. Il suffit d'utiliser le profil forward compatible context pour avoir une API propre, qui casse la compatibilité avec tout ce qui a été écrit pour OpenGL 2. Et jusqu'à présent, chaque nouvelle version a continué d'avancer dans la bonne direction, en phase avec la réalité du matériel moderne.
La seule différence avec un changement brutal (qui était prévu et connu sous le nom de code Long Peaks), c'est que l'on est pas obligé d'utiliser ce profil; en fait le programmeur peut choisir à quel niveau de compatibilité il se place. C'est une contrainte pour les développeurs de drivers, mais absolument pas pour ceux qui utilisent l'API.
Par contre cela laisse la tentation d'utiliser quand même les fonctions obsolètes, là où un changement brutal aurait poussé plus rapidement les développeurs à améliorer leur code.
Quand au problème du design by committee, les coups de gueule poussés à la sortie d'OpenGL 3 ont largement assainit la situation (il suffit de voir le rythme et la qualité des sorties de nouvelles versions depuis).