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.