[haiku-appserver] Re: investigating some bugs - Rudolf have a look at this please

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 30 Mar 2005 09:02:42 +0300

Morning,

Stephan Assmus wrote:
>>      OK, let's see if I have this right.
>>      FrontBuffer = frame buffer. BackBuffer = a buffer the same size as 
>>frame buffer.
>>      If that's the case, where do you put the back buffer when 
>>app_server 
>>runs on haiku with accelerated drivers?
> 
> The backbuffer is in main memory (also on Haiku), for several reasons. 
> Painter can do anti-aliasing, but that would be really slow if the 
> backbuffer would be in graphics mem (because it needs to read from it). 
> Even without anti-aliasing, lots of the drawing_modes need to read 
> pixels. Last but not least, when you alpha blend a bitmap, like 
> something you drag with the mouse, over the backbuffer, it will be much 
> more efficient. I think as long as you don't need to read from the 
> front buffer, having the backbuffer in main memory is just much better.

        Aha. OK.

>>>transfer. For example, in a more advanced version of UpdateQueue, 
>>>it 
>>>could do the transfer within the time of a vertical blank, so that 
>>>front buffer updates are synced with the monitor refresh.
>>
>>      Doesn't that require the back buffer being inside videoMem?
>>      Rudolf?
> 
> 
> No. Why? You might confuse this with page flipping, but that is not 
> what is happening here. Back and front buffer do not get swapped.

        Then how is it that you can sync the updates with monitor refresh?
        AFAIK, that is only possible for a blit operation (both the source
and the target are in videoMem). I may be wrong, but I don't think the
AGP or PCIe bus is fast enough for this operation, Rudolf?

>>>If you find some time to work on the update code.
>>
>>      I will, in a few weeks.
> 
> Hm. I really don't mean to be pushy or anything, but please don't be 
> disappointed if I come up with my own code and/or fixes in the 
> meantime. That's really not ment to discredit your work at all, but I 
> have some time to work on app_server, and I don't see much else which 
> needs to be worked on at the moment. Since the update code does not 
> work at all, nothing else, like for example the controls can be tested. 
> Unless of course you tell me something else which I could do.

        The update code works. Not as it should, but it works. My test window
contains a view which sets it's view color, and that works every time. Your test
app, indeed, shows there are some bugs with the invalidate/redraw mechanism,
I'll fix them even before the update code. (I'll try to do that these days)

        About the update code... I would like you to stay aside. As I said,
this is next on my list and I'm pretty sure you can find other things to do.

        Please, don't touch that code.

        [Try making picture player work, or that is ready? What about Bitmaps,
do they work?]

>>>Here is something you 
>>>should consider. In the current design, I'm seeing that update 
>>>requests 
>>>pile up.
>>
>>      Where? It just overwrites Layer::fUpdate :-)).
> 
> I don't think you see the whole picture. Just drag one window over 
> another window, you will see that the redraw request will *not* get 
> combined, which would be much faster, but pile up and if you hold the 
> mouse still, you can watch app_server process all piled up redraw 
> requests. I don't know how to explain the fix any better than in my 
> previous mail. The problem is *not* the slow ViewDriver. Really.

        I think I am. It's just I did not understood what you wanted in
your previous mail. I know what you are saying: while a ServerWindow/WinBorder
is during an update, combine the new invalid regions for the next update. Of
course I'll do that.


>>      I will consider these words.
>>      However, I have designed the window manager to be effective on 
>>multiple 
>>CPUs systems (as that's the feature) and do as little as possible 
>>context switch with kernel code. So, I used semaphores/locks to a 
>>minimum and let RootLayer thread run pretty much uninterrupted.
>>      You have my word that I will try to make whatever comes best of me 
>>at 
>>that moment, and if I have problems this list will see my posts. :-)
> 
> Well, if you need to serialize the access to certain things in order 
> for it to work correctly, that's what you have to do.

        That why I wrote: "used semaphores/locks to a minimum". ;-)


Bye,
Adi.

Other related posts: