FreeLists / haiku-appserver / [haiku-appserver] Re: BScreen support

["Stephan Assmus" <superstippi@xxxxxx>]

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.