[webkit-dev] Fwd: image downscaling during decoding

2012-08-13 Thread Tom Hudson
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.

(from the right account this time)
webkit-dev mailing list

[webkit-dev] Fwd: Transformations precision: double - float

2012-10-12 Thread Tom Hudson
(again from corrected account)

Originally To: Gabor Rapcsanyi rga...@inf.u-szeged.hu, CC: Mike Reed

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.

webkit-dev mailing list

Re: [webkit-dev] How to switch on MultiSampling for accelerated 2D Canvas?

2012-11-27 Thread Tom Hudson
On Tue, Nov 27, 2012 at 8:00 AM, Kui Zheng kuii.zh...@gmail.com wrote:

 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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

2013-01-10 Thread Tom Hudson
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?

webkit-dev mailing list