User-Agent: Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre Built from http://hg.mozilla.org/mozilla-central/rev/e1d7fd5255fd Content is painted incorrectly if D2D/DW are enabled and the page is scrolled quickly or diagonally. Reproducible: Sometimes Steps to Reproduce: 1.Enable D2D/DW with latest m-c build 2.Scroll a page up and down quickly or scroll horizontally and vertically at the same time Actual Results: Content isn't painted correctly Expected Results: Content should be painted correctly

I can confirm this. -> Confirmed.

I've managed to reproduce. Will investigate.

It appears that the operation of drawing with a ID2D1BitmapBrush with its own render target bitmap as source causes a failure. In some situations this seems to cause rendering artifacts. We should just fallback for this case since it's rare, even with retained layers. A follow-up bug should be filed to investigate more efficiently handling OPERATOR_SOURCE with an opaque D2D surface source and a pixel aligned rectangular mask though. We could use GPU memcpy for that case. We could then support self-copy by ping-ponging to our temp surface and we could optimize image drawing to use this method.

Confirmed on sites like facebook , flash content , songs.pk etc Linux

(In reply to comment #6) > Confirmed on sites like facebook , flash content , songs.pk etc > Linux Since landing of retain layers , i doubt that this is not ONLY caused by D2D , plus i reproduced it on Linux , so ?

Is this related to the bug??? http://img227.imageshack.us/img227/2839/lunapic127947417383792.gif

Probably not. (In reply to comment #7) > Since landing of retain layers , i doubt that this is not ONLY caused by D2D , > plus i reproduced it on Linux , so ? Please file a new bug if you're seeing something like this on Linux. It's entirely possible that we have similar issues on Linux due to the cairo-xlib backend not handling self-copies.

Comment on attachment 457932 [details] [diff] [review] Fallback when attempting self-copy Please add a comment about why this code does it what it does like your comment in the bug.

Pushed http://hg.mozilla.org/mozilla-central/rev/2f270a9da778.

With this build: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100719 Minefield/4.0b2pre ID:20100719110901, Built from http://hg.mozilla.org/mozilla-central/rev/c1791f8ec5fe i got this: http://img840.imageshack.us/img840/1783/bild3.png after fast scrolling. The remainder of the side did not look better.

According to comment 10 I filed a new bug 579736 for Linux but am being redirected here as a duplicate. To clarify, is this the same bug despite this one being marked as Windows 7 only?

scrolling in general now seems slower. However web sites where I was getting multiples of the same line appears to be fixed. I think you are falling back on a lot more sites then you think. Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100719 Minefield/4.0b2pre - Build ID: 20100719112542

(In reply to comment #16) > scrolling in general now seems slower. However web sites where I was getting > multiples of the same line appears to be fixed. I think you are falling back > on a lot more sites then you think. > > Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100719 > Minefield/4.0b2pre - Build ID: 20100719112542 Hrm, perhaps. In any case, that it's somewhat slower is expected. A more advanced fix for the problem is in the works.

For me, this patch seems to have introduced noticeable lag when a hover-link or other item that changes when moused over scrolls under the cursor. If I just grab the scroll bar and shake it very fast, the scrolling is still smooth like it was before. Is there a bug to track the more advanced fix?

(In reply to comment #18) > For me, this patch seems to have introduced noticeable lag when a hover-link or > other item that changes when moused over scrolls under the cursor. If I just > grab the scroll bar and shake it very fast, the scrolling is still smooth like > it was before. Is there a bug to track the more advanced fix? Bug 580109