[haiku-appserver] Re: drawing thread
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 14 Oct 2004 17:56:57 +0300
DarkWyrm wrote:
> 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.
> 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?
In all we do.
>> Please, you have to agree, every time we have a better solution we
>>must take action. That is the
>
> Take action, yes. Immediately? Not necessarily.
Then we agree. :-)
>>>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.
OK, we may be talking different things here.
Optimizations should take place after design and implementation are
finished. If you ask me, design
is subject to change the most often, because not doing so complicates code
_big_ time. And often,
after your code gets out of control, bugs are inevitable. New designs with old
code reuse where
possible is the _best_ programming method.
>> 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
It can be seen we haven't talked in a long time. :-)
I don't know how double buffering at DD level could work. In fact, I'd
really like you to explain
us, cause' you're making me very curious.
My opinion:
I think you are wrong. DisplayDriver is a drawing framework. How it
gets things done it's its
business, it can directly use hardware acceleration or use CPU to draw in
buffers.
You do not need to lock it to use its methods. Instead, those methods
should get a buffer and a
drawing context. Based on those arguments, it draws within specified clipping
region inside buffer.
This way you need not to lock DD, and in a multiprocessor environment is could
be a very good thing
as another CPU could safely draw onscreen the contents of other windows.
Double buffering needs to be controlled by window manager because it is
the one that issues
_UPDATE_ requests. When redrawing of a window is needed, it can very easily
look into window's
offscreen buffer to see what valid areas it has and what exactly needs to be
actually redrawn.
Locking is needed only when double buffering is disabled or when we go
out of memory for the double
buffering process. Still, in the second case we could release the memory of
some minimized or rarely
used windows.
> 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.
Guess you have a different opinion now. :-) Isn't it? :-P
>> 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.
One more argument for Poller thread be the one to do move/resize/blit.
It does not have _any_ impact on interface responsiveness. Poller
execution path is resumed only if
all regions are calculated and all windows have their surface drawn with
_view_color, or better
their valid offscreen surface blit in case of double buffering.
So you see, either we use a different thread for doing all
move/resize/blit operations, or do that
with every ServerWindow thread and hugely complicating things, _or we use_
Poller thread for this
job, this thread must wait for all regions to be rebuilt and all windows/views
to draw their initial
canvas, before processing user input actions.
> 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.
That is because we use BView as a back end. When DD functions will work
in conjunction to
AccelerantDriver this won't be noticeable anymore.
> 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.
Of course.
> 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. :)
While you are invited to do so, I really don't think you'll find a
problem with clipping code. That
code took me some time to complete and I checked it over and over, performance
wise also. IMHO:
there is very little room for improvement and if you want to get rid of this
problem I think you
should have AccelerantDriver working.
Thanks,
Adi.
Other related posts:
