[haiku-appserver] Re: investigating some bugs - Rudolf have a look at this please
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 29 Mar 2005 23:21:09 +0200 CEST
Hi,
> > Now, HWInterface is supposed to be the abstraction of a graphics
> > card.
> > Therefor, it provides all stuff like SetMode(display_mode) and so
> > on.
> > The only important thing however is the BackBuffer, to which
> > DisplayDriverPainter attaches its Painter instace. Then there is a
> > HWInterface::Invalidate(BRect) method, which tells the HWInterface
> > that
> > a certain part of the BackBuffer contains new contents.
>
> 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.
> > 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. They
can even have different color spaces. To be more precise, the front
buffer can have any colorspace, while the transfer from back to front
handles a possible conversion.
> > 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.
> > 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.
> > just as well. What I mean is this: Slow drawing operations are not
> > a
> > problem per se. Piling up drawing requests however is a huge
> > problem,
> > and that is the _true_ cause of the ViewDrivers slowness. So
> > multiple
> > update request should be combined "by some mechanism" and result in
> > only one drawing request. There are multiple approaches to that
> > mechanism.
>
> Doesn't matter if ViewDriver is slow, every drawing instruction
> must be
> shown before that DisplayDriver's method returns.
> And I think on real HW it should work just like that.
> I REALLY don't think we should invest time in making ViewDriver
> faster.
See above. I was in no way talking about making ViewDriver faster. I
was talking about fixing a big design flaw in app_server, that would -
as a side effect - make even ViewDriver actually usable.
> > I don't have a good overview of what happens in the rest of
> > the app_server yet, so I might be totally off here. I think that
> > the
> > server side thread that exists for each window should try to pull
> > update information with a time out, while the thing in app_server
> > that
> > calculates the necessary updates should push the update region with
> > hard locking. Ie, there is a lock that serializes access to the
> > update
> > region (I don't know what locks already exist, and if there should
> > be
> > one per server object or if there is one object holding the
> > clipping
> > information of all layers or what not...). Anyways, the part that
> > sends
> > update requests down to the client windows, which result in them
> > calling Draw() of their child views - this part needs to try to
> > access
> > the update region with a timeout. Next time it tries to access it,
> > it
> > might already have been combined from the previous state and more
> > recent going ons in the app_server. Am I talking sense?
>
> 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.
Best regards,
-Stephan
Other related posts:
