[haiku-appserver] Re: drawing thread
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- Date: Sun, 24 Oct 2004 17:22:04 -0400 EDT
> 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:
