> Hi, > > DW, have you reached a decision regarding double buffering and > one_thread_drawing? Yes, but I'm afraid you won't like the answer, but perhaps you might understand better if I explain myself first. All during last week my schedule was insane, so writing very many e- mails about the whole topic was pretty much not possible, but I'm glad I didn't because in reading the discussion I finally understood that there were two different methods of double-buffering being tossed around. Double-buffering is implemented in all drivers except AccelerantDriver using one large bitmap the size of the screen. When a ServerWindow thread makes a DisplayDriver call, it acquires the driver lock, draws whatever it's going to draw to the buffer, and then does whatever is necessary to get the changed area blitted to the gfx card's framebuffer. ViewDriver, for example, calls Invalidate to force the BView displaying the BBitmap buffer to update the screen. Anyway, it has its good and bad points, but I think that ATM this is the way that we should go. If I understand what you want to implement, each window would have its own buffer which would be drawn to and then the invalid regions would be drawn to the framebuffer. In some ways, this is quite a bit simpler, especially when it comes to window composition. Not that it really has that much effect on us, but this is what OS X and Longhorn do in order to achieve some of the 133t window tricks that they do. In a lot of ways I really like it, but there are some serious problems, too. Two words come to mind, first of all: hardware acceleration. Unless we are usng texture memory, there is no way that I know of to draw to these window bitmaps using the HW acceleration. Even if it were possible, there would be a huge amount of change necessary to do it and do it properly. This would involve major changes to the app_server's architecture itself. I could list them here, but for lack of time, I would rather not. If you would like to know specifics, let me know. Managing the memory used for these buffers could get expensive unless some management techniques are used. Thorough as you are, you probably already thought of that, but I only mention it because it's another part of the server that would have to be implemented in order to do window-bitmap double buffering. One of the things that you didn't like about the current architecture is the whole mess related to moving and resizing. I have no problem with cranking up Poller's priority to help with repsponsiveness -- some of the calls it has to deal with are quite expensive and I think that it could be quite helpful. I wouldn't have thought of that, so I'm glad you brought it up. AFAIK, the drawing thread thing was something we already agreed on. What I am about to ask will probably have us spending more time e- mailing than coding and it's somewhat off-topic because it's R2, but I think it's worthwhile to ask nonetheless: what are you guys' thoughts about the R2 server? Things I know that I've been asked about or would like to see done myself: 1) Hardware-accelerated OpenGL 2) using OpenGL for windowing -- using Adi's thoughts on a double- buffered windowing system on texture memory. 3) Hooks to support a remote-access server 4) Full-fledged OpenType support, including support for OpenType layout 5) Seeing how much new stuff can be used in the R1 to allow for support for older hardware 6) Expansion of availalable video driver hooks to allow for more usage of 2D HW acceleration Thoughts, guys? --DW