Re: [webkit-dev] Parallel image decoders are up for review
Hello, folks. We updated the test results. http://webkit.org/b/90375#c49 We think the performance improvement is promising. @ Summary of the results 1. The response time of interactive web pages were improved by approximately 20%. 2. An embedded device shows a similar performance enhancement as a high-end PC. Thank you. 2012/7/19 Schmindor schmin...@gmail.com: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Thank you letting me know this information! On Tue, Jul 17, 2012 at 5:41 AM, Alpha Lam hc...@chromium.org wrote: Hi! This is great work! There's work in the Chromium port going on that has a similar goal as your parallel image decoding effort. There are some parts that we overlap that I think should be discussed to avoid clashes. What's the current progress of Chromium work? Can I check out the source code? Do you have a design document? Here's some background information of what we're doing. In Chromium port there's a deferred painting mode that we record painting commands and playback (rasterize) on another thread. Recording on the main thread requires images to be synchronously decoded and our current focus is to defer image decoding to a later time and eventually have parallel image decoding. The specific part we overlap is drawing an asynchronously decoded BitmapImage to GraphicsContext. Your patch does the whole image decoding asynchronously while we just care about whether an image can be asynchronously decoded or not. This part in particular I think we should discuss to make sure we're both comfortable with. Our approach also checks if the given image can be decoded asynchronously or not. Please refer to 3.3 Criteria to Use Parallel Image Decoders of our design document. ( https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 ) I certainly want to hear more about your approach here. I'll make a few comments on the patch in the webkit bug. Thanks. I think we can improve both approaches by sharing ideas with each other regarding asynchronous image decoding because they have much in common. Thanks and this is great effort! Alpha 2012/7/9 KwangYul Seo sk...@company100.net Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
2012/7/17 KwangYul Seo sk...@company100.net Thank you letting me know this information! On Tue, Jul 17, 2012 at 5:41 AM, Alpha Lam hc...@chromium.org wrote: Hi! This is great work! There's work in the Chromium port going on that has a similar goal as your parallel image decoding effort. There are some parts that we overlap that I think should be discussed to avoid clashes. What's the current progress of Chromium work? Can I check out the source code? Do you have a design document? We have a work-in-progress design doc that large documents the current WebKit stack for image decoding. The remaining portion is very skia specific since our approach is to do deferred image decoding under SkBitmap (our platform specific bitmap representation). We're still in design phase so you're way ahead of us. :) Here's some background information of what we're doing. In Chromium port there's a deferred painting mode that we record painting commands and playback (rasterize) on another thread. Recording on the main thread requires images to be synchronously decoded and our current focus is to defer image decoding to a later time and eventually have parallel image decoding. The specific part we overlap is drawing an asynchronously decoded BitmapImage to GraphicsContext. Your patch does the whole image decoding asynchronously while we just care about whether an image can be asynchronously decoded or not. This part in particular I think we should discuss to make sure we're both comfortable with. Our approach also checks if the given image can be decoded asynchronously or not. Please refer to 3.3 Criteria to Use Parallel Image Decoders of our design document. ( https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 ) I certainly want to hear more about your approach here. Thanks for sharing the doc. Making comments in the webkit big. Alpha I'll make a few comments on the patch in the webkit bug. Thanks. I think we can improve both approaches by sharing ideas with each other regarding asynchronous image decoding because they have much in common. Thanks and this is great effort! Alpha 2012/7/9 KwangYul Seo sk...@company100.net Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Hi! This is great work! There's work in the Chromium port going on that has a similar goal as your parallel image decoding effort. There are some parts that we overlap that I think should be discussed to avoid clashes. Here's some background information of what we're doing. In Chromium port there's a deferred painting mode that we record painting commands and playback (rasterize) on another thread. Recording on the main thread requires images to be synchronously decoded and our current focus is to defer image decoding to a later time and eventually have parallel image decoding. The specific part we overlap is drawing an asynchronously decoded BitmapImage to GraphicsContext. Your patch does the whole image decoding asynchronously while we just care about whether an image can be asynchronously decoded or not. This part in particular I think we should discuss to make sure we're both comfortable with. I'll make a few comments on the patch in the webkit bug. Thanks and this is great effort! Alpha 2012/7/9 KwangYul Seo sk...@company100.net Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Parallel image decoders are up for review
Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Great job guys! Your approach sounds good. Can you upload an overall patch (not for review) to the main bug? Then we can easily test your solution and see the overall complexity change of the patch. I will test the patch on Qt and keep in touch. Regards, Zoltan On Mon, 09 Jul 2012 10:30:51 +0200, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Thanks. I will upload one monolithic patch (not for review) that you can see to the master bug when I come back to work tomorrow. It is late night in Korea :( I really appreciate your previous work! Regards, Kwang Yul Seo On Mon, Jul 9, 2012 at 10:16 PM, Zoltan Horvath zol...@webkit.org wrote: Great job guys! Your approach sounds good. Can you upload an overall patch (not for review) to the main bug? Then we can easily test your solution and see the overall complexity change of the patch. I will test the patch on Qt and keep in touch. Regards, Zoltan On Mon, 09 Jul 2012 10:30:51 +0200, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_**bug.cgi?id=90375https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/**document/pub?id=**12gf7MhNHfupeR3GdRF-** h2Vzg86viCbwXq8_JByHKlg0https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
On Jul 9, 2012, at 1:30 AM, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Some questions: (1) Do you know of any real-world sites that get a significant benefit? The linked page mentions an artificial test case that gets a large benefit, but shows an inconclusive result for the more general page load benchmark cited. There are definitely image-heavy real-world sites out there, such as http://cuteoverload.com or flickr.com photostream pages. (2) Did you do any testing of time to first paint in addition to page load time? Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Hi, I realized that measuring page loading time here is a bit misleading. Because image decoding is performed lazily in rendering, it is possible that many images are still not decoded when page loading is finished. Parallel image decoders exacerbate this because image decoding is changed to asynchronous. Therefore, to accurately measure the performance improvement, we must measure time to the first paint as Maciej suggested. I will update the test results and add more image heavy real word sites such as cuteoverload.com, flickr.com and pinterest.com. Regards, Kwang Yul Seo On Tue, Jul 10, 2012 at 7:42 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 9, 2012, at 1:30 AM, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Some questions: (1) Do you know of any real-world sites that get a significant benefit? The linked page mentions an artificial test case that gets a large benefit, but shows an inconclusive result for the more general page load benchmark cited. There are definitely image-heavy real-world sites out there, such as http://cuteoverload.com or flickr.com photostream pages. (2) Did you do any testing of time to first paint in addition to page load time? Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
