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 (Invalidate()->RebuildRegions())/Redraw(onlySendsAMessageToClientIIRC)/offScreen-to-Screen-blitting, be done only in Poller thread? Thanks, Adi.