Hi, > Anyway, the idea I had for adding mode support for workspace was > something like this: > > - Every workspace keeps a local display_mode variable. > - There are setter-getter methods for it. > - When a mode GET is issued from client side, the app server > just gets that variable from the right workspace. > - When a mode SET is issues from client side, the app server sets > that variable (eventually checking if it's a supported mode), and, if the workspace is the active one, it sets the display_mode of the... display, too. > - Every time the workspace changes (i. e. from workspace 1 to > workspace 2), the app_server checks if the display_mode of the new workspace is the same of the mode of the new. If it's not, it sets the display_mode of the screen too. > > I guess that's a simple and flexible way to do it. I agree. And I would like to add that I wanted to pull the "HWInterface" instance out of DisplayDriver and remove the display mode and cursor related functions (which it forwards to its HWInterface instance) from the DisplayDriver API. In the end, I would like this API to contain only drawing related functions. The reason is simple: When we support drawing into BBitmaps, we can attach a DisplayDriver instance to a ServerBitmap, but all the cursor and screen mode related functions don't have anything to do with it. Note however, that the existing DisplayDriver code would not have to change (so the drawing functions would still try to hide a software cursor and such, only that the BitmapHWInterface would have empty implementations for that). Which ever part of the code needs the functionality in DisplayDriver to control modes and move the cursor, is the one that will have a HWInterface instance directly. It will have to make sure that the DisplayDriver gets attached to it. Best regards, -Stephan P.S. About performance concerns: Some of the code that the RootLayer thread executes scales pretty bad, for example the algorithm used for rebuilding layer clipping. Before we worry about saving performance by trying to make locking unnecessary, we need to worry about the algorithm first. Otherwise it is a ridiculous discussion. And before we even worry about performance at all, we need a correct implementation. Anything else is premature optimization.