[haiku-appserver] Re: drawing thread
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 14 Oct 2004 07:35:13 -0400 EDT
> 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.
Sorry about all the goofiness with respect to what e-mail is talking
about what. ATM the mailing list is saying that every mail is bouncing.
Funny thing is that I haven't done anything to cause it. :P
Anyway, I did read your second e-mail. I agree that what is in place
for moving and resizing needs to change, but I'm not so sure that using
Poller is the solution because of the serious amount of context
switching.
> > 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.
If you're referring to the "almost all the server's threads accessing
the DisplayDriver" model, I'm afraid that it is inherent to the OS. If
not, what are you referring to?
> 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.
I know that. :)
> 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! )
Take action, yes. Immediately? Not necessarily.
> > 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.
I always have agreed with the statement -- I like optimization, but
doing so at too early a stage in the game can be detrimental instead of
helpful and my experience, while perhaps not as extensive as yours and
many others on the project, has shown more than once this to be true.
> 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.
Yes we are. Double-buffering is internal to the display module and is
not a requirement -- AccelerantDriver is currently not double buffered,
for example, even though I'm assuming that it eventually will. The
BitmapDriver, for example, is also not, but for obvious reasons. Any
time we have two threads sharing access to a common resource, such as
DisplayDriver, there is a need for locking -- unpredictable results
occur otherwise.
> Then we agree window management code
> (Invalidate()->RebuildRegions())/
> Redraw(onlySendsAMessageToClientIIRC)/offScreen-to-Screen-blitting,
> be done only in Poller thread?
Um, no. I agree with you in the problem (code complexity and
performance) and that it needs to be addressed. However, I'm not so
sure I agree with the solution, as I mentioned above. Unless I've
completely missed the boat, the main problem in moving and resizing is
the resource hog that it is. Even on my new machine, it's still
painfullly obvious in the slowness of moving one window over another as
opposed to just moving one around. I haven't really sat down and
thought about this one before, but I want to have us all carefully
consider a number of options before we do anything. Without having
looked at the code this morning, I've been kicking around the idea of
finding out what is involved in the cycle of processing a move and/or
resize operation currently and find out where we can remove
bottlenecks. Let me take some time to look at the code, think a bit,
and get back to you before we go further. :)
--DW
Other related posts:
