Thanks Paul,<br><br>I have logged this issue in <br><br><a href="https://bugs.webkit.org/show_bug.cgi?id=22540">https://bugs.webkit.org/show_bug.cgi?id=22540</a><br><br>regards,<br>Srinivas Rao. M<br><br><br><br><br><div class="gmail_quote">
On Fri, Nov 28, 2008 at 2:04 PM, Paul Pedriana <span dir="ltr">&lt;<a href="mailto:ppedriana@gmail.com">ppedriana@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The ScrollView::paint function seems wrong to me too.<br>
<br>
The function source is shown below. I don&#39;t understand why it uses context-&gt;clip(visibleContentRect()) without accounting for documentDirtyRect. Shouldn&#39;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.<br>

<br>
An simple example of how the screen gets messed up is when you go to <a href="http://www.google.com" target="_blank">www.google.com</a> 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&#39;t happen. Doing it seems to fix it for me though my testing is meager and it may be that somehow there&#39;s a more correct solution.<br>

<br>
void ScrollView::paint(GraphicsContext* context, const IntRect&amp; rect)<br>
{<br>
 &nbsp;if (platformWidget()) {<br>
 &nbsp; &nbsp; &nbsp;Widget::paint(context, rect);<br>
 &nbsp; &nbsp; &nbsp;return;<br>
 &nbsp;}<br>
<br>
 &nbsp;if (context-&gt;paintingDisabled() &amp;&amp; !context-&gt;updatingControlTints())<br>
 &nbsp; &nbsp; &nbsp;return;<br>
<br>
 &nbsp;IntRect documentDirtyRect = rect;<br>
 &nbsp;documentDirtyRect.intersect(frameRect());<br>
<br>
 &nbsp;context-&gt;save();<br>
<br>
 &nbsp;context-&gt;translate(x(), y());<br>
 &nbsp;documentDirtyRect.move(-x(), -y());<br>
<br>
 &nbsp;context-&gt;translate(-scrollX(), -scrollY());<br>
 &nbsp;documentDirtyRect.move(scrollX(), scrollY());<br>
<br>
 &nbsp;context-&gt;clip(visibleContentRect()); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;---- Seems wrong to me.<br>
<br>
 &nbsp;paintContents(context, documentDirtyRect);<br>
<br>
 &nbsp;context-&gt;restore();<br>
 &nbsp; .<br>
 &nbsp; .<br>
 &nbsp; .<br>
}<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
I&#39;ve seen similar issues on a non-DirectFB port, but it turned out to be related to a bug in the ScrollView::paint() method. &nbsp;It wasn&#39;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. &nbsp;Anything that forces a redraw of the widget, of course, fixes it as it will then render the whole area, not just the cursor. &nbsp;I saw it when going to <a href="http://www.apple.com" target="_blank">www.apple.com</a> and watching the updating news area, the headlines change and the title &quot;Hot New Headlines&quot; would get erased everytime it updated.<br>

<br>
dunno if that&#39;s helpful or not.<br>
<br>
On Nov 27, 2008, at 9:35 AM, Srinivas Rao M Hamse wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I am using WebKit+Gtk on DirectFB 1.2.0 &nbsp;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)<br>

<br>
Any idea how to fix this issue ?<br>
<br>
regards,<br>
Srinivas Rao M.<br>
<br>
-- <br>
Srinivas Rao M &nbsp;Hamse<br>
<br>
</blockquote>
<br></div><div class="Ih2E3d">
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br>
</div></blockquote><div><div></div><div class="Wj3C7c">
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Srinivas Rao M &nbsp;Hamse<br><br>