The ScrollView::paint function seems wrong to me too. The function source is shown below. I don't understand why it uses context->clip(visibleContentRect()) without accounting for documentDirtyRect. Shouldn't it make a union of visibleContentRect and documentDirtyRect? I am writing my own graphics back-end and this lack of clipping is messing up the view drawing. An simple example of how the screen gets messed up is when you go to www.google.com and once the page is drawn you simply mouse over one of its two buttons. WebKit calls ScrollView::paint with a rect of the button area and during its rendering in paintContents it proceeds to draw a button-height/screen-width white rectangle before drawing that one button and without pushing a graphics context with the clip rect. This white rectangle is thus not clipped and blows away all pixels to the left and right of the button area, including the other button. If documentDirtyRect clipping was done then this wouldn't happen. Doing it seems to fix it for me though my testing is meager and it may be that somehow there's a more correct solution. void ScrollView::paint(GraphicsContext* context, const IntRect& rect) { if (platformWidget()) { Widget::paint(context, rect); return; } if (context->paintingDisabled() && !context->updatingControlTints()) return; IntRect documentDirtyRect = rect; documentDirtyRect.intersect(frameRect()); context->save(); context->translate(x(), y()); documentDirtyRect.move(-x(), -y()); context->translate(-scrollX(), -scrollY()); documentDirtyRect.move(scrollX(), scrollY()); context->clip(visibleContentRect()); <---- Seems wrong to me. paintContents(context, documentDirtyRect); context->restore(); . . . }

I've seen similar issues on a non-DirectFB port, but it turned out to be related to a bug in the ScrollView::paint() method. It wasn't properly clipping the drawing and when Google was blinking the cursor in the text box, it ends up erasing the whole window instead of just the inner textbox. Anything that forces a redraw of the widget, of course, fixes it as it will then render the whole area, not just the cursor. I saw it when going to www.apple.com and watching the updating news area, the headlines change and the title "Hot New Headlines" would get erased everytime it updated.

dunno if that's helpful or not.

On Nov 27, 2008, at 9:35 AM, Srinivas Rao M Hamse wrote:

...

Hi,

I am using WebKit+Gtk on DirectFB 1.2.0 ported on an arm platform. I am noticing that the render of text input widget is not complete. Attaching a snapshot of google page. In this google text input text box in not drawn. Also seen this issue while rendering other widgets also. WebKit misses some of them at first go. It slowly draws as and when that part of the screen/widget gets refreshed(say by pressing TAB keys)

Any idea how to fix this issue ?

regards, Srinivas Rao M.

-- Srinivas Rao M Hamse

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Paul Pedriana-3 wrote:

The ScrollView::paint function seems wrong to me too.

The function source is shown below. I don't understand why it uses context->clip(visibleContentRect()) without accounting for documentDirtyRect. Shouldn't it make a union of visibleContentRect and documentDirtyRect? I am writing my own graphics back-end and this lack of clipping is messing up the view drawing.

paul, hi, there's a lot more corruption going on than just a few artefacts around buttons - see https://bugs.webkit.org/show_bug.cgi?id=25696 for more details but basically scrolling with mouse or keyboard _completely_ trashes the screen, with artefacts appearing in blue or black or from random memory areas. this is something of a showstopper for an embedded app project so if you or anyone else have any clues as to what needs to be done, fixing this, that would be great. paul if you have some patches already that would be great. l. -- View this message in context: http://www.nabble.com/WebKit-partial-rendering-issue-tp20721190p23487095.htm... Sent from the Webkit mailing list archive at Nabble.com.

https://bugs.webkit.org/show_bug.cgi?id=25696#c2 thanks to paul for the guidance and for the leading work / patches on which this is based, paul, the code that you sent me has a bug where the scrollbars on a frame will go "blank" and disappear when you move the mouse over them. the reason is that the empty rect causes the return out of the paint function, prematurely, i fixed this by allowing the scrollbars always to be painted. if anyone can think of a better way to do this other than to comment out code (even though it can be demonstrated as completely broken) that'd be great. testing this i used http://pyjs.org/showcase/Showcase.html then click on "Frame" (left-hand-side) and then shrink the browser window to 800 pixels to get a horizontal scrollbar in the frame as well. with the patch from the above link, everything's fine. paul, chris, your help was _really_ appreciated. the client will be well-'appy. l. -- View this message in context: http://www.nabble.com/WebKit-partial-rendering-issue-tp20721190p23564079.htm... Sent from the Webkit mailing list archive at Nabble.com.

On Fri, May 15, 2009 at 5:29 PM, David Hyatt <hyatt@apple.com> wrote:

On May 15, 2009, at 12:18 PM, lkcl wrote:

...

https://bugs.webkit.org/show_bug.cgi?id=25696#c2

thanks to paul for the guidance and for the leading work / patches on which this is based, paul, the code that you sent me has a bug where the scrollbars on a frame will go "blank" and disappear when you move the mouse over them. the reason is that the empty rect causes the return out of the paint function, prematurely, i fixed this by allowing the scrollbars always to be painted.

if anyone can think of a better way to do this other than to comment out code (even though it can be demonstrated as completely broken) that'd be great.

There is nothing wrong with the code in ScrollView.cpp that I can see, so I'm not sure why commenting out code would be necessary.

it was the quickest fix possible that i could find - thank you for the suggestion on setting the can blit on scroll flag to false, i'll try to work that into the customers' app. might have to add it to the gtk gobject interface if it's not already there. l.