Par contre si l'intérêt d'Haiku c'est sont framework graphique, ce n'est pas forcément la peine de s'embêter à écrire un OS complet pour ça, ça peut très bien s'écrire au dessus xorg/MIR/wayland et de la bibliothèque XCB (qui, si je me souviens bien, est conçue pour faire de la programmation réactive ce qui colle bien avec des threads).
XCB permet surtout d'avoir un contexte explicitement lie a chaque appel de l'API. Ce qui permet de gerer de multiple thread sans probleme avec plusieurs connections. Le probleme, c'est qu'il n'est toujours pas possible d'utiliser OpenGL avec et donc on doit faire un fallback via Xlib dans la main loop. Ce qui tue un peu tout l'interet.
De maniere general, tous les systemes linux sont concu autour d'un unique canal de communication avec le display server pour les inputs et les ordres au systeme d'affichage. Ceux qui veut forcement dire qu'on a pas mal de boulot dans la main loop. Apres on peut toujours utiliser un thread pour le rendu et pousser le resultat depuis la main loop. C'est ce que font Qt, je crois, et les EFL.
La difference majeur de ce que j'en ai compris, c'est que le thread de rendu est actuellement dans le serveur cote BeOS alors que sur Linux ont a eu une tres forte tendance a s'en eloigner (X vs Wayland). La principale raison cote Linux etant qu'on a plein de toolkit different donc l'interface expose par X est devenu bien trop complexe sans jamais pouvoir repondre au besoin des toolkits. Alors que dans BeOS, le toolkit de BeOS etait integre des le depart et donc le serveur avait un travail moins generique a founir. Probablement que cela aide pour scheduler le rendu en appelant les routines de rendu directement dans le serveur au moment opportun sans utiliser trop de memoire et sans trop de probleme de synchronisation.
[^] # Re: Eh ben...
Posté par cedric . En réponse à la dépêche Haiku se lâche enfin. Évalué à 8.
XCB permet surtout d'avoir un contexte explicitement lie a chaque appel de l'API. Ce qui permet de gerer de multiple thread sans probleme avec plusieurs connections. Le probleme, c'est qu'il n'est toujours pas possible d'utiliser OpenGL avec et donc on doit faire un fallback via Xlib dans la main loop. Ce qui tue un peu tout l'interet.
De maniere general, tous les systemes linux sont concu autour d'un unique canal de communication avec le display server pour les inputs et les ordres au systeme d'affichage. Ceux qui veut forcement dire qu'on a pas mal de boulot dans la main loop. Apres on peut toujours utiliser un thread pour le rendu et pousser le resultat depuis la main loop. C'est ce que font Qt, je crois, et les EFL.
La difference majeur de ce que j'en ai compris, c'est que le thread de rendu est actuellement dans le serveur cote BeOS alors que sur Linux ont a eu une tres forte tendance a s'en eloigner (X vs Wayland). La principale raison cote Linux etant qu'on a plein de toolkit different donc l'interface expose par X est devenu bien trop complexe sans jamais pouvoir repondre au besoin des toolkits. Alors que dans BeOS, le toolkit de BeOS etait integre des le depart et donc le serveur avait un travail moins generique a founir. Probablement que cela aide pour scheduler le rendu en appelant les routines de rendu directement dans le serveur au moment opportun sans utiliser trop de memoire et sans trop de probleme de synchronisation.