Thanks Paul, I have logged this issue in https://bugs.webkit.org/show_bug.cgi?id=22540 regards, Srinivas Rao. M On Fri, Nov 28, 2008 at 2:04 PM, Paul Pedriana <ppedriana@gmail.com> 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.
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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- Srinivas Rao M Hamse