[haiku-appserver] Re: drawing thread

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 26 Oct 2004 19:16:37 -0400 EDT

>       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.
Thank you, my friend. I appreciate that. :)

> 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.
I've been wondering about this myself -- how to optimize it, even 
though I don't plan on doing it yet. The things I've been considering 
are things like changing the locking mechanism to avoid so many context 

> 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.
This is also something I wonder about the more I think about it. The 
purpose is also to reduce the number of invalidation messages being 
passed around. I don't remember where, but I remember seeing some 
source code which used it for this very reason. It's a very good trick 
when used properly. I suspect that it reduces context switching by 
eliminating redundant messages. As a result, I suspect that somehow the 
messages are queued client side, but I'm not sure how we should do it.

>       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.
They might not. I'm not very familiar with MacOS X, as much as I like 
it. If I knew more about video cards and hardware acceleration 
techniques in general, I might be able to answer better. In any event, 
we don't have anything that I'm aware of which would allow us to be 
able to use HW acceleration functions on bitmaps allocated on the heap.

>       If you don't mind, I'd like to hear them when you have some time. 
> Thanks.
I'm typing while sleep-deprived so bear with me. DisplayDriver would 
not exist as we know it -- the rendering buffer and the graphics 
library portions of the class would be separated from each other. I 
suspect that the graphics portions of DisplayDriver would probably end 
up in the Layer class, a la Syllable. Layer itself would receive quite 
a few changes, though not as drastically as DisplayDriver. Most of 
those would involve an access semaphore (directly or by proxy of 
BLocker) for the bitmap and the allocating and freeing of the bitmap. 
In order to conserve RAM usage, it would be necessary to construct a 
memory managemet method which would free bitmaps when they were not 
needed without imposing much of a performance hit. The bitmaps 
themselves would just be allocated off the heap, but I would imagine 
that providing a means to set a fixed limit on the amount of RAM 
consumed would also be a Good Thing (TM) in this situation. 

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


Other related posts: