[Webkit-unassigned] [Bug 36883] [Qt] Parallel painting in WebKit

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 6 00:14:32 PDT 2010


--- Comment #3 from Zoltan Herczeg <zherczeg at webkit.org>  2010-04-06 00:14:30 PST ---
Thank you for your feedbacks again!

Currently only simple pages can be painted with the help of QPicture, which is
capable of recording QPainter events. Since the stream can be stored on the
disk, this class contains all the necessary information for the replay. This is
probably unnecessary for WebKit, since it uses only a subset of these commands,
and keep everything in memory, so no need to store all the attributes in the
stream, sometimes a reference to a WebKit object would be enough.

How the implementation works now:
 - a thread is created for each frame (the owner could be changed to a backing
store). Qt implementation requires a back buffer, since the widget can be
painted only during painting events. No idea about other ports. However, to
avoid screen flickers, a back buffer would be useful on all implementations.
 - the communication happens through message queues. Since all messages are
equally sized, we don't need to free them all the time, we keep maximum of n
for faster message allocation. (n is a compile time constant)
 - since many allocators employs arenas for fast allocation, every resource is
freed on the thread where they were allocated.

Since some other other ports are interested, I try to make the implementation
less platform specific. To do this, the RenderContext messages will be
transmitted instead of QPainters. I will write a simple wrapper for each of
them. The "real" RenderContext will be created on the thread. Since the
RenderContext has no virtual methods, we probably need to put an "if" inside
the implementation:

RetVal RenderContext::anyEvent(args)
    if (hasPaintThread()) // A pain thread :)
    // The original code executes inside the thread:

This is not set in stone, if you have a better idea, just tell me.

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

More information about the webkit-unassigned mailing list