Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, ...). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 6.
Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, ...). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.