[haiku-appserver] Re: progress and status

Hi Stephan,

>I'm not sure about that. Several things: Usually, it is not good to use 
>drawing commands outside of Draw() or to call Draw() directly. Instead, 
>one should always call Invalidate(). On R5, there is some behind the 
>scenes magick, that makes sure that your Draw() function gets only 
>called as often as your app can manage, no matter how often you call 
>Invalidate() in different locked states. If you call Draw() directly, 
>you don't take adventage of that.

Yeah, I think you already told me a couple millions of times :)

>That being said, I think that the code is correct for the synchronous 
>controls version. If we block the window message loop, we obviously 
>don't have Draw() called for us, so we need to call it directly. Not 
>using B_ASYNCHRONOUS_CONTROLS windows is long deprecated, but I know we 
>need to support it nevertheless.

Ok, agreed.

>In our BView implementation, I think that the different drawing 
>commands don't flush the app_server link. They simply place a message 
>into the queue. The command doesn't get executed until something else 
>causes the queue to be flushed. In the drawing methods, I think we 
>should differentiate wether we are currently called from within Draw() 
>or just like that. In the later case, we should automatically flush. I 
>don't know how R5 handles this.

I just had a small discussion with Marc Flerackers about that.
He said that r5 flushes the command buffer every time a reply is needed AND 
PERIODICALLY (probably in the looper thread). R5 can do that because graphic 
messages aren't really messages, but instead, there is a stream of commands. 
That's one of the reasons why BMessages weren't used for this task: Bmessages 
need to be completed before being sent (there is no support for incomplete 
BMessages), a stream of commands does not need to: the app server can just 
start drawing as soon as it gets the first command.
That's a big difference from what we have, because BPortLink still 
sends/receives complete messages. I don't know if we can flush the ports 
periodically too, and what would happen if we started doing that.

Note: I suggest you to  speak with Marc as he's the guru in there, this is just 
what I've understood :P

>I know that you need to 
Sync() a BView 
>that is attached to a BBitmap. But for normal views, I never >need to 
>sync anything, but I don't call drawing methods outside of >Draw() in 
>any of my apps, so I don't have any experience with that.

>If blocking inside MouseDown(), the messages from the >app_server should 
>still be appended to the queue, and if this does not happen, >then its a 
>bug. Do you want to investigate this?

I haven't tested after your latest changes, I suspect that the Flush() you 
added (in BTextView::Highlight()) fixes the problems in there, so it could just 
be a missing Flush() somewhere. But still I think we should find a way to 
auto-flush the drawing commands.


Stefano Ceccherini aka Jack Burton
---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------

Other related posts: