Bug 148572 – [Win][HighDPI] Repaint issues after scrolling.

• Component: WebKit Misc.
• Status: NEW

After scrolling, there are often some repaint artifacts on Windows. This can for example be seen when looking at a bugreport on bugs.webkit.org.

Created attachment 260175 [details]
Patch

(In reply to comment #1)
> Created attachment 260175 [details]
> Patch

I'm not sure this is the best solution.
Maybe it is better to fix this without adding another member variable to WebView?

This patch is not correct because the FrameView parameter always is the main frame, giving incorrect results for scrolling frames other than the main frame.

Created attachment 260923 [details]
Patch

(In reply to comment #4)
> Created attachment 260923 [details]
> Patch

Fixed by repainting entire scroll area, but maybe it would be better to fix this by always rounding the device scale factor off to the nearest integer?

[Alex Christensen]

There's got to be a better way to do this. What about just adding a pixel to each side of the rect?

(In reply to comment #6)
> There's got to be a better way to do this. What about just adding a pixel to
> each side of the rect?

Yes, I agree that we should find another way :)
I may not understand you correctly, but I don't think the problem is that we haven't invalidated a large enough area. Instead, the problem seems to be that after a few calls to the scroll method, we have blitted the contents to the wrong position, so that when "normal" drawing is performed, there are glitches between the blitted areas and the areas drawn "normally". The reason for this is that repeated conversions from floating point scroll deltas to integer deltas, is accumulating the error from each conversion. Maybe there exists some WebCore methods which will give us the correct deltas in pixels so the blitted areas end up at the correct position?

[Alex Christensen]

Comment on attachment 260923 [details]
Patch

I don't think this is a good idea.  It covers up a bug and hurts performance.  I think this might be specific to WinCairo because scrollNonCompositedContents takes an IntSize.  I think we should actually find what is the problem and fix that.

(In reply to comment #8)
> Comment on attachment 260923 [details]
> Patch
> 
> I don't think this is a good idea.  It covers up a bug and hurts
> performance.  I think this might be specific to WinCairo because
> scrollNonCompositedContents takes an IntSize.  I think we should actually
> find what is the problem and fix that.

Ok, I'll have a closer look :) I'm not sure that it is WinCairo only, though, since the bug is present when not in accelerated compositing mode. For me it happens with a device scale factor of 1.25, and e.g. hovering over a button after scrolling (dragging the scroll knob) on bugs.webkit.org.