There won't be any modifications to WebCore classes. We will be implementing this on top of Threaded Coordinated Graphics in GTK+ port. So there will be some modifications to Coordinated Graphics, specifically in CoordinatedTile part.
I'm not sure what "on top of a rasterizer instead of inside the rasterizer" means, but deferred rendering does not have any impact on Canvas rasterization. Canvas rasterization will be the same as current behavior. Regarding Images, cairo_recording_surface will be referencing PixelData in ImageFrame for rasterization. There is a problem where ImageFrame might be destroyed before the rasterizing thread actually rasterizes the image. We are currently looking for a way to solve this problem. On Sat, May 25, 2013 at 3:36 AM, Benjamin Poulain <[email protected]>wrote: > On Fri, May 24, 2013 at 2:43 AM, Jae Hyun Park <[email protected]>wrote: > >> Our team is planning on upstreaming Deferred Rendering in GTK+ port. >> >> Deferred Rendering is a parallelization technique to perform >> rasterization on a dedicated thread to improve performance. >> >> We have published our design document in the link below: >> >> https://docs.google.com/document/d/1K4q7KtPzsm6c7qUnHqW0NtAv7uItxgs35QZJvHsfLjY/pub >> >> We have also created meta bug in WebKit bugzilla. >> https://bugs.webkit.org/show_bug.cgi?id=116713 >> >> Any comments/concerns are appreciated. >> > > A few questions: > > What kind of modifications are needed for your implementation? > Since you do that on top of a rasterizer instead of inside the rasterizer, > how do you deal with Images, Canvas, etc? > > Benjamin >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
