[haiku-appserver] Re: drawing thread

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 25 Oct 2004 23:48:57 +0300

Hi,

DarkWyrm wrote:
>>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.

        What can I say... I'm a bit disappointed. But what can I do, you are 
the team leader and you get the final word. :-) So, we'll do it like you 
want it. ;-) Still, I'd like to answer a few phrases in this email.

> 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.

1.      Locking is done for every drawing instruction.
2.      Blitting is done for every instruction instead of when an update is 
over. IF you have a 200x200 rect in which random lines are drawn, 
imagine what drawing with the CPU in the backbuffer(vidMem) then blit on 
frontbuffer would mean.
3.      From the BeBook: "DisableUpdates() , EnableUpdates()
These functions disable automatic updating within the window, and 
re-enable it again. Any drawing that's done while updates are disabled 
is suppressed until updates are re-enabled. If you're doing a lot of 
drawing within the window, and you want the results of the drawing to 
appear all at once, you should disable updates, draw, and then re-enable 
updates."
        This looks to me like an off screen window is created (maybe in 
videoMem, but I seriously doubt it as the frame buffer is screen's width 
and height and there are only the overlay hooks available for allocating 
mem in video memory) with the contents copied of what's visible on 
screen then all drawing is done in there and when EnableUpdates() is 
called this surface is copied on screen. Correct me if I am wrong.
        This must be implemented.


> 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.

        Yes. Update requests would be sent to BWindow only when 
BView::Invalidate() is called.

> 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.

        As I already said, I don't think they keep their primary buffers in 
videoMemory; writing with the CPU in there is expensive, and windows do 
a lot of writing which cannot be accelerated. They may be using HW 
acceleration if they do triple buffering just like we have discussed - a 
second buffer in video Memory. Still, that means we first have to do 
double buffering first.

> 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.

        If you don't mind, I'd like to hear them when you have some time. 
Thanks.

> 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.

        You are right. Things like big windows and the amount of memory used.

> 
> 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.

        OKay, then I'll make sure all redrawing will be done in Poller thread. 
Very glad you agreed. :-)

> 
> 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

        I'll answer tomorrow about these subjects. Sleepy now... :-)


Bye,
Adi.

Other related posts: