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.