[webkit-dev] WebKit partial rendering issue

[Paul Pedriana]

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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>