[Webkit-unassigned] [Bug 36883] Generic parallel painting in WebKit with Qt backend

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36883





--- Comment #17 from Simon Hausmann <hausmann at webkit.org>  2010-04-20 17:21:55 PST ---
On a high-level there are two things that come to my mind:

1) Rendering into a QPicture is very cheap. Replaying the QPicture on the real
paint engine is likely to consume most of the painting time, as only at that
point expensive operations such as path drawing and glyph rasterization happen.
Therefore these operations are not parallelized.

2) I see three main "CPU" consumers in WebKit: JavaScript execution, document
layout and painting. This approach parallelizes only the rendering, and in the
Qt case only a smaller portion of it.

I admit this is where I like the WebKit2 model of doing the entire heavy
lifting in either a secondary thread or a process.

My guts feeling is that the threaded approach is more interesting for embedding
applications and that it would be nice to scale up the process model to more
than one process (one per tab, like in chrome?) based on the WebKit2 work.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.