<br><div><br><div class="gmail_quote">On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Aug 13, 2012, at 11:08 AM, Alpha Lam &lt;<a href="mailto:hclam@chromium.org" target="_blank">hclam@chromium.org</a>&gt; wrote:</div><br><blockquote type="cite">
<span style="color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">That&#39;s a good point. I&#39;m not sure but a safe bet would be after RenderView is layout&#39;ed then iterate through images to start decoding.</span><div style="color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">

<br></div><div style="color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport.</div></blockquote><div><br>
</div></div><div>This approach is probably safe (as far as I know) but would have the downside of an extra pass over the whole render tree, or else overhead of maintaining an up-to-date list of rendered images; and it would happen very close to painting.</div>
<div><br></div></div></div></blockquote><div><br></div><div>Yes, the problem is that we don&#39;t have much time between layout and painting because painting is usually  immediately followed by layout. I&#39;m skeptical about the gain we could get by triggering image decoding in the layout phase, but I&#39;d like to defer the conclusion until we have real numbers.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>I think to some extent, benefit from parallelism is in direct tension with benefit from lazy on-demand decoding.</div>
<div><br></div></div></div></blockquote><div><br></div><div>Unfortunately, yes. Because of the lazy nature of image decoding, we don&#39;t have much time for decoding before images need to be painted. So we skip image decoding (and just trigger decoding in the background) in the first paint pass and update the decoded images later.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Note by the way that in general many kinds of render objects can result in rendering images, not just RenderImage. Consider the various forms of CSS images (CSS backgrounds, CSS content property pointing to an image, etc).</div>
<div><br></div></div></div></blockquote><div><br></div><div>We made CSS background, border and mask images be decoded by parallel image decoders. </div><div><br></div><div><a href="https://bugs.webkit.org/show_bug.cgi?id=91203">https://bugs.webkit.org/show_bug.cgi?id=91203</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Regards,</div><div>Maciej</div><div><div class="h5">
<div><br></div><blockquote type="cite"><br><div class="gmail_quote">2012/8/13 Alpha (Hin-Chung) Lam <span dir="ltr">&lt;<a href="mailto:hclam@google.com" target="_blank">hclam@google.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That&#39;s a good point. I&#39;m not sure but a safe bet would be after RenderView is layout&#39;ed then iterate through images to start decoding.<div><br></div><div>The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport.</div>

<span><font color="#888888">
<div><br></div><div>Alpha</div></font></span><div><div><div><br><div class="gmail_quote">2012/8/13 Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The thing I&#39;m not confident of is whether an image&#39;s position in absolute coordinates can be changed by an ancestor after RenderImage::layout completes. It would be helpful if a layout expert would weigh in.<br>
<span><font color="#888888"><br>
 - Maciej<br>
</font></span><div><br>
On Aug 13, 2012, at 3:20 AM, Dong Seong Hwang &lt;<a href="mailto:luxtella@company100.net" target="_blank">luxtella@company100.net</a>&gt; wrote:<br>
<br>
&gt; <a href="https://bugs.webkit.org/show_bug.cgi?id=90375#c80" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=90375#c80</a><br>
&gt;<br>
&gt; In the above link, Hin-Chung shows how to determine whether an image<br>
&gt; is actually painted.<br>
&gt;<br>
&gt; 2012/8/13 Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;:<br>
&gt;&gt; I that case, starting async decoding at layout time makes sense if and only<br>
&gt;&gt; if at layout to e you can predict what you will paint. I don&#39;t know enough<br>
&gt;&gt; about our rendering to know of that is the case.<br>
&gt;&gt;<br>
&gt;&gt; - Maciej<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Aug 12, 2012, at 5:34 PM, Peter Kasting &lt;<a href="mailto:pkasting@chromium.org" target="_blank">pkasting@chromium.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Why not start asynchronous decoding immediately as the image is loading,<br>
&gt;&gt;&gt; and synchronize at paint time? What is the benefit of waiting until layout<br>
&gt;&gt;&gt; time to start decoding the image data?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Uninformed guess (since I haven&#39;t touched the decoders in a while), but<br>
&gt;&gt; currently we don&#39;t decode unless the image is actually painted, which helps<br>
&gt;&gt; a ton on pages that are an enormous long string of images (common cases:<br>
&gt;&gt; Boston Big Picture blog, various porn sites), since most of the images can<br>
&gt;&gt; be decoded after initial layout, or not at all (if the user never scrolls<br>
&gt;&gt; down enough).  If we started decoding as images loaded I&#39;d imagine we&#39;d do<br>
&gt;&gt; (possibly a lot of) extra work compared to today.<br>
&gt;&gt;<br>
&gt;&gt; PK<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; webkit-dev mailing list<br>
&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
&gt;&gt; <a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
&gt;&gt;<br>
<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/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</div></blockquote></div><br></div>
</div></div></blockquote></div><br>
</blockquote></div></div></div><br></div><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
<br></blockquote></div><br></div>