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 <[EMAIL PROTECTED]> 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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- Srinivas Rao M Hamse
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
