[haiku-appserver] Re: drawing thread
- From: Adi Oanca <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 13 Oct 2004 09:05:00 +0300
Gabe Yoder wrote:
>> I think it's time for a drawing thread inside app_server.
>
>
> Perhaps. That remains to be seen.
OK.
>> ATM invalidating and drawing is done from almost every thread in
>>app_server. IMHO this is not that good as we do need a lot of locking, and
>>code flow is hard to follow. I propose we have methods like ::Invalidate,
>>::Redraw, which if executed from another thread than this drawing_thread,
>>automatically send port messages for the requested action.
>
>
> Reducing the amount of required locking is probably a good thing, although I
> am not totally clear on what you are proposing as a replacement to the
> current system (it might help if I paid more attention to the current
> implementation of the desktop code). Could you elborate more on the system
> that you have in mind?
Sure.
ATM, every ServerWindow and Poller thread do lots of things.
While some are good, with some other I don't agree.
Things I like and agree:
Poller thread receives input events and based on those, it selects,
moves windows, resize them and sends _UPDATE_ messages to
clients(BWindows). If you think about it, you may call this thread a
windowManagerThread.
Things I do not like:
ServerWindow thread also does moving and resizing and implicitly send
_UPDATE_ messages. This, IMHO is bad, mainly because window management
code flow is split between a lot of threads. Other reasons are excessive
locking and possibly thread starvation, as you have suggested. Why that?
Because when a window moves or resizes there is a lot of math
involved(BRegion) in visible region calculation. As we want this
processing to be done fast we need to increase priority for every
ServerWindow thread. IMHO, this is bad. (thread starvation)
The alternative would be for Poller thread to be a higher priority
thread and be the only one to make calculations for moving and resizing
windows - (visible region calculation). (ServerWindow threads would send
_MOVE_/_RESIZE_ port messages)
Drawing, contrary to my first impression, is not a problem, IMHO.
Thread starvation can be avoided because all ServerWindow threads have
the same, normal, priority and the only other thread which draws
on-screen is Poller thread - window borders and view_color fill.
Double buffering is not a problem as locking DisplayDriver is not
necessary for drawing operations because we draw in an off-screen
surface. However, we need to lock at some point and that is when bliting
from offscreen to frame buffer.
> One advantage that I can see to having a single drawing thread that receive a
> bunch of messages is that it could allow us to prevent starvation for access
> to the DisplayDriver. If I am not mistaken, under the current system with
> all of the threads making calls to the DisplayDriver, we could end up in a
> situation where a thread or group of threads keeps hammering on the
> DisplayDriver, and another thread never manages to get the lock because
> everybody else manages to cut ahead in line.
That will not happen. Every thread in the system will run. If low in
priority will just not get that much CPU.
> If we have a single thread
> responsible for drawing, we can just fire off the message and build up a
> queue of things to do (assuming that there isn't some risk of starvation in
> passing the messages). Of course, this whole argument is meaningless if
> there is some sort of FIFO mechanism on the Lock.
As we can avoid starvation, this involves additional port communication
and context switch. While the idea is good, I don't think we need it.
Anymore :-))
>> In this thread I think it is better we also execute window manager's code.
>>This thread would wait for input data (mouse events, keyboard events,
>>invalidate_or_redraw_messages) and move/resize/hide/show windows by calling
>>::Invalidate and :: Redraw() methods.
>
> Again, some more elaboration might help. Maybe it is just because I am tired
> and am not an expert on stuff outside of the DisplayDriver.
You have my explanation above.
> I now have the
> urge to say "Throw me a frickin bone" in a bad British accent.
:-)) Sorry. My bad. :-)
Adi.
Other related posts:
