FreeLists / haiku-appserver / [haiku-appserver] Re: drawing thread

["DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>]

> > It's a very good trick 
> > when used properly. I suspect that it reduces context switching by 
> > eliminating redundant messages. As a result, I suspect that somehow 
> > the 
> > messages are queued client side, but I'm not sure how we should do 
> > it.
> 
>       Wait, you may be confusing things... (me too also :-) )
>       IMHO:
>       Disable/EnableUpdates() disable/enable _UPDATE_ messages being sent 
> to client side thus issuing a 
> BView::Draw().
>       Begin/EndViewTransaction() caches the whole BView::Draw() in a 
> BPicture just like you said - for 
> every BView in window. When EndViewTransaction() is called, 
> app_server will update each affected 
> view (the ones for which BPicture is not empty(or NULL)) but instead 
> of sending the _UPDATE_ message 
> if renders the associated BPicture's data.
>       What do you think?
I agree that I was getting them confused in my bleariness. ooooook. :D 
I *like* the BPicture idea.

> > The bitmaps 
> > themselves would just be allocated off the heap, but I would 
> > imagine 
> > that providing a means to set a fixed limit on the amount of RAM 
> > consumed would also be a Good Thing (TM) in this situation.
> 
>       Yup, I think so too: 1/3rd ?
I was thinking this could be a user setting and figuring out the good 
default when we do it for R2.

--DW