[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.
--DW
Other related posts:
