Hi, Stephan Assmus wrote: >>>Yes, there will be CopyRegion() and CopyRegionList() which uses the >>>first. There won't be a CopyBits() in DisplayDriver anymore. >>>CopyRegion() will do the topological sorting of the rects and call >>>some >>>internal worker function to do the actual inplace copy of a rect. >> >> I don't think that is a good idea. One must apply the topological >>sort on all the rects that are to be blit. For that reason I think >>CopyRegionList() must be the one to do the sort. You cannot blit >>rects >>of a region and then continue with the next region, that may overlap/ >>overwrite >>rects that still need to be blit. > > > I have not implemented it in this way yet. I do understand what you > say, but I'm not sure the sorting will work for multiple BRegions > copied with different offset each. Maybe CopyRegionList should assume > the list of BRegions is already sorted itself, so that even if > overwriting takes place, it takes place in the right order and does no > harm. Nope, that won't work. All rects must be ordered, otherwise I don't see how to avoid artifacts. Then, I think we should do as Be did - completely redraw center and right aligned views. At least I don't see another way. > Next up: I will see how far scrolling is implemented as of now. Hehe, you will have a bit of work to do that. :-) bye, Adi.