[haiku-appserver] Re: GetMouse()

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 30 May 2005 15:19:19 +0300

Axel Dörfler wrote:
> 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()).

        I'm not too happy with this method. I think it does not respect
the logic, in general. I just asked for mouse coordinates, not for a UI
update. The fact is that I can call GetMouse() from everywhere in window's
context and not actually wanting to update the UI.

        IMO, in R2 this method should only return mouse location and
buttons. What do you think? Also I think we should remove support for
synchronous controls in R2. Opinions?

>>      Another question of mine, is why does GetMouse in R5/Haiku
>>dispatches _UPDATE_ messages?
> 
> Do we really have to go over that again?

        It's a bit different now... :-)

>>      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.

        Yes, I agree... Drawing should be done from window's thread because
that's what it was introduced for.

>>>>    BTW, if you to this:
>>>>Invalidate(rect);
>>>>Window()->UpdateIfNeeded();
>>      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.

        In our app_server Sync() does that.

> 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).

        Oh well... I just warned.

>>>>(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?

        No, no... DoUpdate() calls Draw() methods for every view that's
inside the invalidated rect.
        DoUpdate() must not be modified, instead we should ask synchronously
the server if it has an invalid region to pass to us, and force a 2nd update
if one supplied. (DoUpdate() still has to be cleaned up. :-) Will do that
someday)


bye,
Adi.

Other related posts: