Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Thu, Jan 10, 2013 at 8:37 AM, Maciej Stachowiak m...@apple.com wrote: The reason I ask is that this sounds like a significant increase in complexity, so we should be very confident that there is a real and major benefit. One thing I wonder about is how common it is to have enough of the page processed that the user could interact with it in principle, yet still have large parsing chunks remaining which would prevent that interaction from being smooth. Another thing I wonder about is whether yielding to the event loop more aggressively could achieve a similar benefit at a much lower complexity cost. I don't want to let this point of Maciej's slip away: on mobile we may have fewer cores than desktop, and we're paying a pretty high complexity burden for multiple threads already; some of Nat's awesome recent work in Chromium is too multithreaded for my comfort. I'd back-of-enveloped yielding during page layout and guessed it wasn't worthwhile, but do we know that yielding during parsing isn't? Tom ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to switch on MultiSampling for accelerated 2D Canvas?
On Tue, Nov 27, 2012 at 8:00 AM, Kui Zheng kuii.zh...@gmail.com wrote: Hi, I was trying to accelerate path filling using stencil buffer, For antialiasing, we rely on GPU multisampling. So, I want to know Does webkit support Multisampling for accelerated 2D Canvas? how to switch on it? Thanks for you help. I believe the details of this depend on which port you're using. For Chromium, the graphics layer is Skia, and you can get a more targeted answer on the skia-discuss mailing list. However, Chromium already uses the stencil buffer for some path rendering, and we've found it to be considerably *slower* than a software implementation in common web use cases. Tom (from the right email address this time) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fwd: Transformations precision: double - float
(again from corrected account) Originally To: Gabor Rapcsanyi rga...@inf.u-szeged.hu, CC: Mike Reed r...@google.com Do you have particular bottleneck functions that you have reason to believe would benefit from ARM SIMD optimizations? Under what workloads, and how much benefit? We've see a few ridiculously expensive transform functions in WebKit that my colleagues in Chapel Hill might be able to recall, but usually it's the rendering engines that are hot, not WebKit itself. We have seen places where double math appears to be absolutely required for correctness: matrix inversion and path convexity testing; there are some other areas we're experimenting with that seem to require it as well. You'd probably need to survey WebKit for stability (or just hack in doubles and run layout tests) to see how many other places will break if you throw away the extra precision. The rest of Chromium's renderer (Skia) uses float, and we've deployed SSE/NEON and played with float vs double quite a bit there. The float-double conversion at the WebKit/Skia boundary doesn't seem to be too much of a drag, but doing it in any sort of inner loop can really kill performance. Meanwhile, there are a lot of places where switching from ARM assembly to NEON in the renderer hasn't given us as much win as we'd hoped for, which is why the question how much benefit? seems important to answer before spending too much time polishing a set of typedefs. Tom ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fwd: image downscaling during decoding
On Mon, Aug 13, 2012 at 9:39 AM, Anton Obzhirov a.obzhi...@samsung.comwrote: ** We are looking for ways to improve page loading speed and reduce memory usage for WebKit in general and for GTK port of WebKit in particular. One of the ideas is to implement downscaling of the images during decoding for image elements with rectangle less then original image size. At the moment such images are full decoded to a full size buffer and get downscaled during rendering. It can be quite beneficial in term of memory usage and should speed up rendering of the pages like image galleries for example. So what are your thoughts about it? Interesting idea! I know Chrome sees memory pressure from the downsampling two-step on some pages, so I'd think this is could be useful for us, too. Isn't it going to require fairly large and intrusive changes to several different third-party libraries, though? Also, different ports use different image downscaling algorithms; I can think of ways to try to enable incremental downscaling callbacks so you don't have to implement N downscales in each of M decoders, but none that are both general and performant. I'd love to see a proposal on this. Tom (from the right account this time) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
