Hi, first, let me say that I really like what Axel is proposing in every single detail. I have thought along the same lines. I try to keep this email short. Please re-read what Axel wrote about ServerScreen and then go look at the actual code. It is currently much more straight forward to think of ServerScreen as a representation of a physically attached screen. So a ServerScreen manages a graphics driver (or later possibly one output of a graphics card). In this setup, it is clear how to configure a physical screen. For example, when a Workspace becomes active, it is clear that it uses the ServerScreen instance to change resolution, color space etc. I know that some of you had something different in mind at first, but again, just look at the code, it is just obvious where it goes from there. Maybe we can rename it to PhysicalScreen if that makes everybody more happy. Second, I really love the idea to think of a Workspace as a container for a certain configuration of the physical screen(s). When multiple independant physical screens are supported, one Workspace will represent a certain setting of _all_ the screens. Before you disagree... this is pretty much exactly the way workspaces work now on R5. For example, you might have all workspaces configured the same - save one, which is configured to have the video overlay on the external output of your laptop and has the resolution that fits your beamer. When you make a presentation or want to watch a video, you simply switch to that workspace and everything is setup. What Axel has proposed will allow for exactly this elegant way of using workspaces. Just extended to multiple screens. Third... DarkWyrm and Adi keep mentioning that the code has to be the way it is, and that it being complicated is because of the complexity of the app_server. Sorry, but I have to disagree. The app_server really has _no_ reason of being so hard to understand as it currently is for a new developper joinging the team. And this really hurts development. Everyone having come to the team had this first impression. The code containing so many errors is just proof of it. Please, I don't mean to hurt anyones feelings. I would not want anyone to have a look at the WonderBrush code right now. I know how hard it is to be brave and refactor almost your entire code base. I understand this is code that has grown. So I would say, please, have some trust in Axel, let him do his magic, it can only help. The problem is that many of the central classes _don't_ currently have clear responsibilities, and that makes the code flow very hard to follow. Refactoring the classes to make the code flow more clear will help app_server a great deal, I'm sure of that. And the responsibilities for the classes that Axel has layed out, really make a lot of sense to me. Encapsulation and forcing certain code paths can really do wonders for the robustness and correctness of the app_server, and that is one thing that it is still lacking in many places. Best regards, -Stephan P.S. I have started work on drawing into bitmaps a couple days ago, but I had to work over the weekend. I hope to have something ready by the end of the week though.