[haiku-appserver] Re: drawing thread

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 12 Oct 2004 17:59:40 -0400 EDT

> Hi,
>       I think it's time for a drawing thread inside app_server.
>       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.
>       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.
>       Comments, suggestions?
With the exception of the difficulty of following the code flow, I 
completely disagree.

1) This model works fine for Syllable and AtheOS -- there are no 
problems with responsiveness. Considering that our server follows the 
very same architechture, we should be ok.
2) Bugfixes and filling in missing bits, not reimplementations of 
significant portions of code.
3) "Premature optimization is the root of all evil."  -- Michael Phipps
4) There is a lot of locking because there are a lot of threads all 
wanting to use the graphics subsystem at the same time.
5) a FIFO system will require just as many context switches because of 
the use of ports. 
6) DisplayDriver locking is done for each call, so each thread should 
only have to wait a short time to execute. Certain calls will more than 
likely take longer than others, such as StrokeLineArray and Stroke/Fill 
Shape over, say, StrokeLine. Like Axel said, ownership of a semaphore 
is passed from thread to thread in the order in which it was acquired.
7) Almost every thread in the server does invalidating and redrawing 
stuff because only the Picasso thread is dedicated to something other 
than fielding messages from some client application.

R5's server has three threads which perform the same tasks as those in 
ours used by the AppServer class. I can't seem to think of a reason why 
Poller shouldn't process something like the window management code 
considering that I look at Poller doing something like a 
DispatchMessage on messages received from the input server.


Other related posts: