[haiku-appserver] Re: scrolling

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 28 Apr 2005 22:28:49 +0300

Hi,

Stephan Assmus wrote:
> Hi,
> 
> scrolling is somewhat functional already. These are the current 
> problems:
> 
> 1) child views need to be moved along
> 2) clipping needs to be updated
> 3) scrolling needs to be synced with redraws
> 
> About 1): It looks like some of the "moving along" takes already place. 
> The drawing of the child views is actually at the correct place. Maybe 
> it even works already once the clipping is updated.
> 
> About 2): I still only feel comfortable with the drawing backend. So 
> any help here is appreciated. I want to trigger rebuilding of clipping 
> regions for the scrolling layer and all child layers.

        I'd like to help, but just too tired right now... sorry.

        If you want to trigger just a redraw, then GoRedraw(*WinBorder*, 
region) will work. If you want to trigger a region rebuilding then do a 
GoInvalidate(_WinBorder_, region).
        There is a catch with the later one I'm afraid, and scrolling I think 
is directly affected. GoInvalidate() automatically calculates the 
regions which have to be moved as well as those that need to be redrawn. 
It's actually quite nice, but, for scrolling to benefit from that, the 
invalidate code needs to be aware of Layer origin. (Invalidate code 
works with screen regions, it doesn't care about local coordinates).
        A change in that matter, I don't think it's hard, but ATM I just don't 
see it - too tired. If you have some patience I will get onto that from 
Tuesday as I'll be out of town until then. (Orthodox Easter) If not, 
don't get angry on me :-). (Working at the cleaner version of the region 
rebuilding(invalidate) code)

> About 3): This is an interesting fact. Scrolling will move parts of a 
> view into visibility. For these parts, update requests are triggered. 
> The next scrolling needs to
> a) wait for all redraws to have happened or
> b) exclude the "yet to be updated" regions from the CopyBits() 
> operation.
> The second option is probably the one we should pick.

        Agree. As I said, that Layer's local coordinates need to be fully 
supported in region rebuilding code.

> The "region in 
> update" is saved somewhere, no? Which one is it?

        WinBorder::fUpdateReg.
        Note this region is not enough for your scrolling. This is the region 
"in update". Meanwhile other regions of that WinBorder may be 
invalidated and because we cannot interfere with the update which is in 
progress, we cumulate those in WinBorder::zUpdateReg.

        Yes, I know... :-) refactoring is needed. Soon.

> Best regards,

        I'd like to explain something in case you didn't know/realized. If a 
layer's position or size is affected, regions need to be rebuilt. In the 
current design, the only one allowed to do that is RootLayer's thread. 
That thread does not block on semaphores, it justs executes as fast as 
possible. (There are 2 exceptions, but that is the general idea). So, if 
you want just to draw or make operations that do not affect Layer 
visible regions then one should do that from ServerWindow's thread, 
otherwise put a handler in RootLayer's thread and send a message.
        I say this because that is the way to go for scrolling and because I 
really care on this design that is thought for multiple processors and 
future per-window double buffering.


Thanks,
Adi.

Other related posts: