[webkit-dev] WebKit partial rendering issue

[Srinivas Rao M Hamse]

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



-- 
Srinivas Rao M  Hamse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081128/b775fb19/attachment.html>