[haiku-appserver] Re: drawing thread
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 27 Oct 2004 06:24:18 -0400 EDT
> > 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
Other related posts:
