[haiku-appserver] Re: drawing thread

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: