FreeLists / haiku-appserver / [haiku-appserver] Scrolling (was Re: breakthrough)

[Stephan Aßmus <superstippi@xxxxxx>]

Hi Adi and all,

> > How come it used to work before? (or didn't it, and we just didn't
> > notice?)
> 
>     Apparently I must be blind.
>     Frames for every BView are updated with Stephan's code which
> handles B_VIEW_RESIZED/MOVED messages. This is valuable for the clipping
> code that is in place. Only the new clipping code had this problem.
> 
>     Sorry, for bothering you. ;-)

I was wondering all along while reading the messages... :-) The "big" 
message was sent for _all_ views having been resized on the server side. 
The checking for the B_FRAME_EVENTS was done on the client side with my 
code. In another words, the old clipping code had the same problem, and I 
solved this with the "one message for all invalid views" thing. When you 
redesigned the clipping code, you probably were not aware of my changes for 
the old code. :-)

Anyways, nice this is solved now.

But something else... about the scrolling problem. I'm pretty sure that I 
know what the reason is. (IIRC, I have written about this before.) The 
problem is that you can Scroll() an area on the client side, which contains 
dirty regions. In another words, the scrolling when it is performed on the 
server side needs to scroll the dirty region as well.

Here is an illustration of the problem:

+++++++++++++++
+             +
+             +
+    XXX      +
+             +
+             +
+             +
+             +
+++++++++++++++

We scroll this two lines up:

+++++++++++++++
+    XXX      +
+             +
+             +
+             +
+             +
###############    area marked for redraw
###############
+++++++++++++++

Now scroll up again (one line):


+++++++++++++++
+             +
+             +
+             +
+             +
###############    (Ups, we scrolled an area which has not been
###############       repainted yet)
XXXXXXXXXXXXXXX         newly revealed area, marked for update
+++++++++++++++


+++++++++++++++
+    XXX      +
+             +
+             +
+             +
###############    there is no repaint request for this area
+             +    repainted area
+             +
+++++++++++++++

The repaint events from the first and second scroll have been combined, but 
both events combine only to the two bottom lines, because the first repaint 
event has not been scrolled itself before combining with the second event.

All of this makes sense if you consider the asynchronous nature of the 
design. For example, this might be the message queue of the window:

1) MouseMoved
2) MouseMoved

process top event -> Scroll -> queue is now:

1) MouseMoved
2) Repaint

process top event -> Scroll -> queue is now:

1) Repaint
2) Repaint

... of course, it doesn't work quite like that, but this is just to 
illustrate the problem. I know that redraw requests are combined in the 
server and so on. But the nature of the problem is what I wrote, I think.

Sorry for the lengthy mail. I have not slept much, and I am too tired to 
compact my mail.... I hope you forgive me. And I do hope I could shed some 
light into what I think is the scrolling problem.

Best regards,
-Stephan