>> >> I think if we want to avoid this the way to do it may be to just take >> the intersection of the currently visible screen area and the >> destination area and mark just that as dirty. > > That could work but maybe we also have problems with calculating > intersects. The ATI docs say SC values can be negative (Range -8192 to > 8191) but we don't seem to handle that correctly. I don't know if any > drivers use negative values in scissor clipping, I've only noticed it when > checking with different values so maybe that's not be a problem in common > cases. >
Ah, right, we're not currently handling negative clipping values. We're also not applying clipping to the dst on the ctx passed into ati_set_dirty right now. Given that, for v2 I went ahead and did this intersection as-is. It'll mean overmarking dirty in some cases, but no more than the previous implementation and I think it's something we can fix separately. >> Even fixing the unit issue >> the old bounds check would miss blits that began outside of the visible >> screen and continued onto the visible screen. > > Maybe this is the real reason but I still don't see how a relatively small > blit of one character in a fully visible xterm not even near the left of > screen could be missed this way if the screen is panned so I'm still > suspecting clipping might have something to do with this. Not marking out > of screen updates also does not explain that so it's probably just wrong > calculation of visible area. Or you meant that's just another way the > current calculation could miss updates. Yes that's possible. > Yep, I just meant this is another way the current calculation can miss updates. >> Another thought, we could clear dirty bits on full screen updates. But >> that's a change with a much larger blast radius and I would be nervous to >> make it. > > Can we invalidate dirty rect in ati_vga_set_offset to avoid changing vga? > v2 is incoming with the intersection approach. If that doesn't work out we can investigate this further.
