Cette terminologie est enracinée dans l'histoire d'OpenGL. Ce qui est important à retenir, c'est que, pour la plupart des versions GL qui sont pertinentes ici, OpenGL a évolué de manière incrémentielle et en ajoutant de nouvelles fonctionnalités à une API déjà existante plutôt que de changer l'API.
La première version d'OpenGL n'avait aucun de ces types d'objets. Le dessin a été réalisé en émettant plusieurs appels glBegin / glEnd, et un problème avec ce modèle était qu'il était très inefficace, en termes de surcharge d'appel de fonction.
OpenGL 1.1 a pris les premières mesures pour y remédier en introduisant des tableaux de vertex. Au lieu de spécifier directement les données de sommet, vous pouvez désormais les obtenir à partir de tableaux C / C ++ - d'où le nom. Donc, un tableau de sommets n'est que cela - un tableau de sommets et l'état GL requis pour les spécifier.
La prochaine évolution majeure est venue avec GL 1.5 et a permis de stocker des données de vertex array dans la mémoire GPU plutôt que dans la mémoire système ("côté client"). Une faiblesse de la spécification GL 1.1 vertex array était que l'ensemble complet des données de vertex devait être transféré au GPU chaque fois que vous vouliez l'utiliser; s'il était déjà sur le GPU, ce transfert pourrait être évité et des gains de performances potentiels pourraient être réalisés.
Un nouveau type d'objet GL a donc été créé pour permettre le stockage de ces données sur le GPU. Tout comme un objet de texture est utilisé pour stocker des données de texture, un objet tampon de sommet stocke des données de sommet. Il s'agit en fait d'un cas particulier d'un type d'objet tampon plus général qui peut stocker des données non spécifiques.
L'API pour l'utilisation des objets de tampon de vertex était adossée à l'API de tableaux de vertex déjà existante, c'est pourquoi vous voyez des choses étranges comme la conversion de décalages d'octets en pointeurs. Nous avons donc maintenant une API de tableaux de sommets qui stocke simplement l'état, les données étant obtenues à partir d'objets tampons plutôt qu'à partir de tableaux en mémoire.
Cela nous amène presque à la fin de notre histoire. L'API résultante était assez verbeuse lorsqu'il s'agissait de spécifier l'état du tableau de sommets, donc une autre voie d'optimisation était de créer un nouveau type d'objet qui collectait tout cet état ensemble, permettait plusieurs changements d'état de tableau de sommets dans un seul appel d'API et autorisait les GPU pour effectuer potentiellement des optimisations en raison de pouvoir savoir à l'avance quel état allait être utilisé.
Entrez l'objet de tableau de sommets, qui collecte tout cela ensemble.
Donc, pour résumer, un tableau de sommets a commencé sa vie comme une collection d'états et de données (stockés dans un tableau) pour dessiner avec. Un tampon de vertex remplace le stockage de la matrice en mémoire par un type d'objet GL, laissant la matrice de vertex juste en état. Un objet tableau de sommets n'est qu'un objet conteneur pour cet état, ce qui permet de le modifier plus facilement et avec moins d'appels d'API.
char* buffer = socketRead();
(pseudocode). Le journal, d'autre part, vit tout au long du cycle de vie de l'application. Donc, vous créez un tableau quelque part et commencez à lire le socket, chaque fois que vous obtenez des données que vous écrivez ce morceau dans le tableau, vous donnant une liste soignée de toutes les données que vous avez reçues.