[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 #20 from Zoltan Herczeg <zherczeg at webkit.org>  2010-04-28 14:02:51 PST ---
> My point remains even with a platform-independent implementation of QPicture,
> doesn't it? Just recording the paint commands should be considerably less work
> than _actually_ rasterizing text, tesselating polygons and uploading textures.

I am not sure I understand your point. The WebKit (main) thread does not
rasterize anything in my patch. Just send the GraphicsContext commands to a
paintihng thread. Such commands are "draw a rectangle" "draw a text", "clip to
a path". It is nothing to with WebGl, textures are not handled. This approach
advantage over QPicture is that I don't need to stream all data to a buffer, a
reference counted pointer is enough to share a resource between threads.
(Although now I simplifed the patch to copy most of the data, since it requires
less changes in WebKit.)

> Less threading related, but I wonder how well things work with "recording"
> WebKit's painting into GL display lists :)

Do you want to drop the current 2D GraphicsContext and move to a fully OpenGL
based rendering? OpenGL has a similar approach, true, and maybe a reasonable
approach, although the clipping capabilities of OpenGL as far more limited than
QPainter and such contexts.

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