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 161350
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Lamda
by rayiner on Mon 11th Sep 2006 17:33 UTC 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