Linked by Thom Holwerda on Sun 10th Sep 2006 18:00 UTC
BeOS & Derivatives Jerome 'Korli' Duval has adapted Haiku's MESA-based OpenGL subsystem to an addon format, allowing renderers to be plugged in, with the first one being a MESA software renderer. This system will allow hardware 3D renderering drivers, such as Rudolf's one when adapted, to plug in without requiring specialised libGL.so's for every card. This extends the common BeOS concept of modularity even further, and is somewhat similar to how Be's OpenGL beta worked - each graphics card acquired a third, .3da driver, to add to the kernel and .accelerant drivers.
Thread beginning with comment 161269
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Lamda
by axeld on Mon 11th Sep 2006 10:26 UTC in reply to "RE[4]: Lamda"
axeld
Member since:
2005-07-07

To rayiner: The BeOS kernel has no optimizations for GUI whatsoever; it just uses a priority based scheduler. Like Linux it can and will schedule unrelated threads during window resize or other heavy GUI operations.

The only argument that plays off is the window manager being part of the app_server - and that's an argument against X server performance and design. Windows and BeOS have obviously solved this problem in a better way.

Reply Parent Score: 4

RE[6]: Lamda
by rayiner on Mon 11th Sep 2006 17:33 in reply to "RE[5]: Lamda"
rayiner Member since:
2005-07-06

The BeOS kernel does have an optimization for the GUI. Window threads in BeOS run at a higher priority than regular threads. This is not as overtly hackish a solution as Windows's (the foreground app gets a prio boost and a longer timeslice), and its well-subsumed into the general scheduling mechanism, but there is still a B_DISPLAY_PRIORITY that is distinct from B_NORMAL_PRIORITY.

According to an old Be Newsletter, BeOS's probabalistic scheduler will be much more likely to choose a thread with priority 15 (B_DISPLAY_PRIORITY), than a normal one with priority 10. That means when the app_server sends a "redraw" or "resized" message to the application, it is highly probable that the next thread to be run will be the window thread in question.

Reply Parent Score: 1