[haiku-appserver] Re: GetMouse()
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 30 May 2005 12:51:42 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> >> Maybe we are talking different things... To recall: you don't
> >>agree with the fact that UpdateIfNeeded() must be called from
> >>BWindow's thread only=3F
> > Only in "extreme" situations like GetMouse(), yes.
> What makes GetMouse() "extreme"?
Now that you say it - probably nothing. I always think that it needs to
poll, but instead, it just searches the message queue, or gets the
information from the app_server directly. What makes GetMouse() need to
use UpdateIfNecessary() is not GetMouse() itself but the context it's
usually used in (MouseDown()).
So I think you're right, it's not necessary to let it process _UPDATE_
messages when called from another thread.
> Another question of mine, is why does GetMouse in R5/Haiku
> dispatches _UPDATE_ messages?
Do we really have to go over that again?
> Yet another question. Once we have locked BWindow's thread
> from another thread and we are drawing from there, why shouldn't we
> be able to call UpdateIfNeeded() so that any pending update requests
> be resolved from there too? We have locked the window thread, why not
> be able to do almost all operations from another thread? I for
> one, find it useful to call UpdateIfNeeded() from another thread from
> which I'm drawing(and invalidating) stuff.
In R5, you're not supposed to draw from another thread. If you're
needing to call UpdateIfNeeded() from another thread, you're probably
doing something the wrong way :-)
But to deviate from Be's standard answer: maybe we should try to port
or develop a single threaded application, and see, if we can't make it
work in this case, ie. if it's beneficial.
> >> BTW, if you to this:
> >>Invalidate(rect);
> >>Window()->UpdateIfNeeded();
> >> with our current implementation, it's quite possible you won't
> >>get the result you're looking for (ie. the rect being redrawn). Why
> > > =3F
> >>The
> >>=5FUPDATE=5F message may not yet have arrived in BWindow's port
> > > queue.
> > Yes, but that's perfectly okay since you didn't use it properly :-)
> > A Flush() would be what you have to use here.
> Not even a Sync() would assure me a _UPDATE_ message is in port's
> queue.
A Sync() *must* make sure that all drawing operations you did before
are actually applied to the canvas. It's not about _UPDATE_ at all,
AFAICT; it's more or less only needed when you have a bitmap and intend
to operate on it directly (by accessing its bits).
Invalidate() is already enough for normal needs.
UpdateIfNeeded() is not supposed to be called under normal conditions.
Only if the looper is blocked longer than normal (ie. in case of a
BAlert). That GetMouse() does it for you too, is a convenience offer,
that also makes sure that you never have to call it yourself. You (as a
developer) should not need to call this message at all.
> >>(remember what I told you a couple weeks ago=3F)
> > I've no idea what you're referring to, sorry.
> "I'm still not sure about this method. What I think it should do,
> is
> process the _UPDATE_ request that is pending in the message queue,
> just
> as GetMouse() does, and above that, it should query the server if
> there
> still are invalid regions to be updated (regions that became invalid
> since the server sent the last _UPDATE_ request) and if there are do,
> get the data from the reply and do a DispatchMessage(updateMsg, this)
> again."
I thought DoUpdate() does that already? Or was that only the plan?
Bye,
Axel.
Other related posts:
