[haiku-appserver] Re: BScreen support

Stefano Ceccherini wrote:
>>Separating tasks for/in threads makes it easier for the code >to be 
>>maintained and
>>enforces the concept of multi-threading, BeOS is very proud >of. >:-)
> 
> 
> Yes, but the problem in this case is that RootLayer ends up to be the class 
> doing
  everything, which has to know about every other class, and that's much more a
  problem for maintainance.

        That's not true.
        RootLayer's thread only concern is the integrity of the picture shown 
on screen.
For that it must have the correct clipping regions, and for that it must be 
aware of all
the moving and resizing of windows/views currently visible.
        If you must change the resolution then it must recalculate the visible 
areas for
some Layers that may have lost some portions of their ex-visible areas.

        ATM RootLayer's thread has a very clean handler - it is concerned with
moving/resizing, adding/removing of WinBorders and Layers (will come shortly, 
there are
some TODOs about this) and invalidating after, as well as simple invalidate
commands. I have doubts Only about one thing - if we should receive input 
events in this
thread.

> 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.

        Sounds perfect. :-)

> I guess that's a simple and flexible way to do it.
> THOUGH: Currently, as RootLayer is the one which does everything, RootLayer 
> will need to
 > know about DisplayDriver as well (to set the mode), and we end up in the 
 > above discussion. :)

        Things are simple enough here too...
        If the display_mode differs send a message to RootLayer thread and let 
him do that
change for you. In any case RootLayer will have (you can implement that if you 
want :-) ) to
follow the exact steps when changing workspaces with different resolutions.

        The mode you chose with you latest checkin is not nice. Plus, you have 
to clear all
visible regions of Layers present in the current(old+new workspace if changing 
wks) workspace
and finally issue a invalidate request for the whole screen. Note that 
invalidation is done
only from RootLayer's thread - requests can come from everywhere.


bye,
Adi.

Other related posts: