[haiku-appserver] Re: drawing thread

> 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

Other related posts: