Re: [webkit-dev] Chromium for Android builders have been added to the EWS
Nice work. I assume your upstreaming is done. On Fri, Aug 10, 2012 at 6:47 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Nice to hear and congratulation with getting so far! I am very happy that you are aiming at having a working mobile port in trunk; similar goals that we have for the Qt port. Same for the BlackBerry port. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Chromium for Android builders have been added to the EWS
On Sun, Aug 12, 2012 at 4:20 PM, Antonio Gomes toniki...@gmail.com wrote: Nice work. I assume your upstreaming is done. We are getting very close! API compatibility is the next milestone (which only is one or two APIs away at this point), after which the remaining code is mostly long-term work (Text Autosizing and some compositor features). On Fri, Aug 10, 2012 at 6:47 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Nice to hear and congratulation with getting so far! I am very happy that you are aiming at having a working mobile port in trunk; similar goals that we have for the Qt port. Same for the BlackBerry port. Cool! The more, the merrier, of course. Peter -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of multithreaded image decoding
On Aug 10, 2012, at 3:47 PM, Alpha Lam hc...@chromium.org wrote: This is a very valid concern. The question you raised is one topic I want to discuss more broadly. Chromium has a separate rasterization stage so there is some time for decoders to work, synchronization can happen in rasterization stage. This doesn't mean Chromium won't benefit if decoding starts before draw time. For other ports without rasterization stage this approach alone would have the problem you mentioned. Just like you suggested decoding have to start before paint time and then synchronize at paint time. One approach is to start asynchronous decoding during layout time. When an image is downloaded metadata is decoded synchronously and triggers a layout when intrinsic dimension is available. This could be the time to check with current viewport and start asynchronous decoding. For image used as background of a RenderBox we can also start decoding if the rectangle of the RenderBox intersect with viewport. Why not start asynchronous decoding immediately as the image is loading, and synchronize at paint time? What is the benefit of waiting until layout time to start decoding the image data? Regards, Maciej Alpha 2012/8/10 James Robinson jam...@google.com On Thu, Aug 9, 2012 at 5:10 PM, Alpha Lam hc...@chromium.org wrote: Hi everyone! A few weeks ago some folks from company100.net have started a thread of multithreaded (parallel) image decoding in WebKit. We have worked together since then to get a better idea how to complete this feature. I would like to report on the progress and our plan. (The goal for Chromium is slightly different but it will reuse most of the architecture discussed here.) Master bug: https://bugs.webkit.org/show_bug.cgi?id=90375 In WebKit today image rendering is progressive, meaning that image is rendered as bytes are received from the network. This is done through ImageObserver and CachedImageClient interfaces. Multithreaded image decoding uses the same notification architecture, clients of BitmapImage are notified when a new region is decoded and available for painting. Today image decoding happens synchronously when a BitmapImage is drawn into a GraphicsContext. We plan to use the draw operation as a trigger to start image decoding asynchronously. Which means the first draw of BitmapImage will get a transparent image, subsequent draws will have the most recently decoded bitmap. I don't think this approach will work terribly well (at least not by itself). It seems to require that we flash at least one frame without the image data even when we really do have it available. For instance, imagine a page with a number of small image resources (small enough that they all load completely in roughly the same instant), or cached image resources, that impact the layout of the page. Today, when the images load we will redo the layout to accomodate the resources size, then at paint time decode the images and render them. The user never sees an intermediate state unless the resources isn't fully loaded at paint time. With this proposal, the user would always see a flash where the images occupy layout space but are not actually rendered. I think that will be an unacceptably bad user experience. To do this, I think you either need deeper integration with the raster system to make sure that it actually renders the images on the first paint (perhaps by deferring the actual raster ops to give the decoder some time), or kicking off the decode steps sooner and adding synchronization at paint time to make sure we actually see the pixels. I'm really happy someone is looking into these difficult issues. - James This architecture will take several steps: https://bugs.webkit.org/show_bug.cgi?id=93467 This modifies ImageSource to be asynchronous. ImageSource is used as the public interface for decoding images. By making this interface asynchronous individual port can implement parallel image decoding or a similar architecture. This change is ready for review. I would like to get more feedback on the interface since this touches all ports. https://bugs.webkit.org/show_bug.cgi?id=93590 Progressive painting of an image may not be possible everywhere. For example canvas and accelerated-composited img requires synchronous decoding. We plan to keep synchronous decoding the default case. This change identifies code location where asynchronous decoding is possible and tell BitmapImage asynchronous image decoding is requested. After these two changes we will be able to implement multithreaded image decoder inside BitmapImage and ImageSource. I will report on the progress once we get to this point. Alpha ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of multithreaded image decoding
On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote: Why not start asynchronous decoding immediately as the image is loading, and synchronize at paint time? What is the benefit of waiting until layout time to start decoding the image data? Uninformed guess (since I haven't touched the decoders in a while), but currently we don't decode unless the image is actually painted, which helps a ton on pages that are an enormous long string of images (common cases: Boston Big Picture blog, various porn sites), since most of the images can be decoded after initial layout, or not at all (if the user never scrolls down enough). If we started decoding as images loaded I'd imagine we'd do (possibly a lot of) extra work compared to today. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
And down it goes again... On Fri, Aug 10, 2012 at 11:14 AM, Levi Weintraub le...@google.com wrote: We're back! On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo pe...@chromium.orgwrote: It's been down for the past hour, again. Just a nudge in case it slipped through. Peter On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba o...@inf.u-szeged.huwrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? br, Ossy Osztrogonac Csaba írta: It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of multithreaded image decoding
I that case, starting async decoding at layout time makes sense if and only if at layout to e you can predict what you will paint. I don't know enough about our rendering to know of that is the case. - Maciej On Aug 12, 2012, at 5:34 PM, Peter Kasting pkast...@chromium.org wrote: On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote: Why not start asynchronous decoding immediately as the image is loading, and synchronize at paint time? What is the benefit of waiting until layout time to start decoding the image data? Uninformed guess (since I haven't touched the decoders in a while), but currently we don't decode unless the image is actually painted, which helps a ton on pages that are an enormous long string of images (common cases: Boston Big Picture blog, various porn sites), since most of the images can be decoded after initial layout, or not at all (if the user never scrolls down enough). If we started decoding as images loaded I'd imagine we'd do (possibly a lot of) extra work compared to today. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
On Aug 12, 2012, at 6:26 PM, Florin Malita fmal...@google.com wrote: And down it goes again… It is down for me as well… Dirk PS: Sorry, I always wanted to that :D On Fri, Aug 10, 2012 at 11:14 AM, Levi Weintraub le...@google.com wrote: We're back! On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo pe...@chromium.org wrote: It's been down for the past hour, again. Just a nudge in case it slipped through. Peter On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? br, Ossy Osztrogonac Csaba írta: It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? ___ 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 ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?
As a quick follow-up, in Chrome 21 the usage histogram tells ~80% of slice call is still using webkitSlice (no wonder as unprefixed slice was rolled out just half a month ago). Since we started showing a deprecation message I hope the number changes over time. slice usage: 22.61% webkitSlice usage: 77.39% On Mon, Jun 11, 2012 at 3:55 PM, Kinuko Yasuda kin...@chromium.org wrote: On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote: Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. We've been shipping the prefixed version for a year now (in Chrome 11-19 and in Safari 5), so I propose keeping the prefixed version too for now, but to start showing a deprecation message to encourage migration. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda kin...@chromium.orgwrote: Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ 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
