[haiku-appserver] Re: drawing thread

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 14 Oct 2004 10:44:08 +0300

Hi again,

        First, I have apologize for writing about a new thread. I was coding 
something for 
RootLayer+Workspace and I felt it is wrong to call ::Redraw/::Invalidate from 
so many threads. At 
that moment I felt there is a need for drawing thread, and then immediately 
wrote to you.
        Guess I was wrong about a new thread; thanks for clearing that out.
        However in my second email, I stood and analyzed with care the things I 
don't like about current 
architecture. Please respond to that email.

>> 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.

        The idea about a new thread, yes, it's wrong. Sending invalidate, 
redraw or blit messages to Poller 
thread is something that I insist on.

> 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.

        Good for them. It doesn't mean we have to follow the same lines as they 
do. You have 3 years 
experience with app_server, I have 1 year, Gabe has 3; we're all evolving into 
better us. We are 
_very_ capable of doing something better.
        Server architecture will change, always into better, because if we 
don't do that, we'll end up with 
lots of patches and workarounds. Trust me, I'm having Nortel Networks' switch 
code in front of my 
eyes for the last 7 months. And we're not even ready with app_server, 
architecture like every thing 
else, is subject to change. You are looking at AGG, aren't you. I'm redesigning 
Desktop code into 
something much simpler, our messaging code has been changed by Phatz, etc.
        Please, you have to agree, every time we have a better solution we must 
take action. That is the 
difference between open/free source and corporate business. (corporate: the 
code works: OK, DON't 
change it! )

> 2) Bugfixes and filling in missing bits, not reimplementations of
> significant portions of code.

        Yes, you are right. But this is a bug and also a performance issue.
        This does not require reimplementation of significant code, just pass 
some messages to Poller thread.
        I'm not against reimplementations, at the same time I have to agree we 
must finish this project.

> 3) "Premature optimization is the root of all evil."  -- Michael Phipps

        Never agreed with that statement. Redesign of a certain component is 
always a good thing.

> 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.

        Agreed. (not always, read my other email please)

> 5) a FIFO system will require just as many context switches because of
> the use of ports.

        Agreed. (see my other email)

> 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.

        Not entirely true. Because we're using double buffering we're in no 
need to lock for each 
DisplayDriver method call. Only lock/unlock offscreen bitmap.
        If not using double buffering, then yes, we must lock at each DD call.

> 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.

        Which is _bad_. (see my other email)

> 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.

        Yes, my final thoughts also.

        Then we agree window management code 
be done only in Poller thread?


Other related posts: