[haiku-appserver] Re: drawing thread

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 19 Oct 2004 16:40:06 +0300


        Sorry for the delay, I was out of town for a few days. :-)

DarkWyrm wrote:
>>>Yes we are. Double-buffering is internal to the display module and 
>>>not a requirement -- AccelerantDriver is currently not double 
>>>for example, even though I'm assuming that it eventually will. The
>>      It can be seen we haven't talked in a long time. :-)
>>      I don't know how double buffering at DD level could work. In fact, 
>>I'd really like you to explain 
>>us, cause' you're making me very curious.
> The actual DisplayDriver class doesn't actually do anything with 
> respect to double-buffering -- it's actually up to the subclass. I'll 
> use the now-obsolete ScreenDriver and DirectDriver as examples. 
> DirectDriver's architecture is set up such that gfx calls are written 
> to a BBitmap and updated rectangles are put into a FIFO pipe which the 
> updater thread pulls rectangle. AcquireBuffer calls return a pointer to 
> the BBitmap. As such, it very much is double-buffered.

        Heh, that's not double buffering. That's plain bitmap drawing. :-)
        I really don't how are you going to do this. I have explained how this 
could be done, now I'm asking you to give me an elaborate explanation 
because I'm not getting anything. :-( :-)

        If you want to do d.b. at DD level, the _only_ way I see it, is by 
buffering every Layer, and in DrawData you should have a pointer to 
Layer's associated [off-screen]bitmap. If you ask me, that's bad. You 
have to allocate dozens of areas each one containing one Layer's data, 
not even talking about the semaphores needed to access them. As far as I 
see it, d.b. should be done at window/WinBorder level. Allocate an 
off-screen surface(area) to hold entire window's surface and each view 
should write into that area. When updating is done, blit on-screen.

> Calls in 
> ScreenDriver (before I really broke it) wrote directly to the 
> framebuffer. IIRC AccelerantDriver calls HW-acceleration functions 
> where appropriate and otherwise uses software calls to write directly 
> to the frame buffer.

        DD is free to chose the best way to do things. The double buffered 
window manager is not concerned how drawing is done or if the blitting 
process is HW accelerated.

>>      My opinion:
>>      I think you are wrong. DisplayDriver is a drawing framework. How it 
>>gets things done it's its 
>>business, it can directly use hardware acceleration or use CPU to 
>>draw in buffers.
>>      You do not need to lock it to use its methods. Instead, those 
>>methods should get a buffer and a 
>>drawing context. Based on those arguments, it draws within specified 
>>clipping region inside buffer. 
>>This way you need not to lock DD, and in a multiprocessor environment 
>>is could be a very good thing 
>>as another CPU could safely draw onscreen the contents of other 
>>      Double buffering needs to be controlled by window manager because 
>>it is the one that issues 
>>_UPDATE_ requests. When redrawing of a window is needed, it can very 
>>easily look into window's 
>>offscreen buffer to see what valid areas it has and what exactly 
>>needs to be actually redrawn.
> What about when two different threads need to write to overlapping 
> areas of the screen?  An excellent example would be when a developer
> goofs and overlaps two sibling BViews.

        DW, come on... Why do we calculate visibility regions? Why do we always 
draw from back to front?
        OK, to answer to precisely:
        With the help of visibility regions, if two views overlap, it is always 
that the newest view will get the common region. The result: the old 
view will draw in it's full_region-common_region, the new view in 
        If the newest view is transparent, then the visible region of the older 
view will contain the common region also, and the back to front drawing 
order will assure us the correct result is shown.
        And to add the final ingredient:
        Didn't we agreed blitting will be made from on thread only? 

> up or keeping both copies up-to-date gets pretty hairy when screen 
> composition is done.

        That's why access to an off-screen surface will be guarded by a 
semaphore. ;-) Imagine the number of semaphores you'll be needing if you 
want to cache every Layer. :-))
        If I'm thinking better, there is no point in doing double buffering at 
Layer level because we'll be using much more memory when, in fact, we 
only show "a fraction" of it - visible_region. And if we do that, what 
we'll be using as a reference for the off-screen bitmap size? 
full_region? BAD idea, as it can be very big! visible_area? Yes, that's 
OK, but then again isn't this what we exactly cache if we only cache the 
entire window?
        Wait there is more: if we cache a Layer and it has a child right in the 
middle of it which occupies 90% of its surface, how do we allocate the 
associated off-screen bitmap? If we make it after the full or visible 
region them we'll end up with a 90% unused bitmap. BAAAAD! :-)
        Same is valuable of off-screen windows/WinBorders, but this is at least 
justified, as it's the reason why we do double buffering.

> Parallel access like what you describe is 
> something that I want for after R1 -- not before.

        A big NO.
        Unless you have a simpler or faster :-) or easier to implement 
solution... :-)
        Plus, we don't have any code in place for d.b.!

> Locking is necessary 
> because we are heavily multithreaded.

        Of course, when needed! If it can be avoided, WHY NOT?

>>      Locking is needed only when double buffering is disabled or when we 
>>go out of memory for the double 
>>buffering process. Still, in the second case we could release the 
>>memory of some minimized or rarely 
>>used windows.
>>>BitmapDriver, for example, is also not, but for obvious reasons. 
>>>time we have two threads sharing access to a common resource, such 
>>>DisplayDriver, there is a need for locking -- unpredictable results 
>>>occur otherwise.
>>      Guess you have a different opinion now. :-) Isn't it? :-P
> Not at all.

        You should have now. :-))

> My opinion has stayed the same. What you are proposing for 
> changes to the DisplayDriver system is more like what Longhorn has 
> done, and the entire system is definitely something that will work, but 
> it's also an order of magnitude different from what's in place.

        Don't care about Longhorn. The link I gave you was just to show you 
what I already had in mind. I've been thinking about d.b. for maaaaany 
months. :-)
        Why are you under impression the DD that I'm proposing is that 
different from what is in place? I think we have 99% in place. What is 
needed, is that every drawing instruction should have the off-screen 
buffer to draw into as a parameter. That buffer is already locked with 
the help of Acquire/ReleaseBuffer(FBBitmap *bmp);
        Now think a bit, if we disable d.b., we'll be using one buffer only, 
the frame buffer, and that's 99% of what we have now. We only need that 
extra parameter.

> I hate 
> to sound like I don't care about what you think -- I do -- but we need 
> to stick with what we've got.

        We don't have double buffering code!

> If we keep doing major redesigns of 
> significant portions of the app_server, we will _never_ finish.

        Sure we will. App_server design will be ready the day we reach BETA 
stage (fully functional, but with bugs). Until that moment we must do 
the best we can. Notice that, I DID NOT said nothing about 
optimizations, only about re/design.

> At this 
> point, that is the major goal I've got in store is to push so that we 
> actually have an alpha sometime next year.

        I'm sure we will.


Other related posts: