[Webkit-unassigned] [Bug 102994] [META][Qt] Implement Threaded Coordinated Graphics in WebKit1

[bugzilla-daemon at webkit.org]

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





--- Comment #10 from Huang Dongsung <luxtella at company100.net>  2012-12-18 19:03:17 PST ---
(In reply to comment #8)
> Why is that? WebKit trunk does not support Qt 4.8 and instead requires Qt 5.0.

Oops, you are right :)

> > As I read your comment, it is obvious that we need to use something like RunLoop to run AC on the rendering thread.
> > This plan would not create (4) option. This plan improve (2) and (3) option.
> > 
> > In the (2) option, we will composite content into a imageBuffer on the rendering thread using TextureMapperImagebuffer, and QWidget will paint the result into a given QPainter.
> > 
> > In the (3) option, we will composite content into a texture on the rendering thread usint TextureMapperGL, and QGraphicsView  will paint the result texture into QGLWidget's surface.
> 
> While I agree that this would work I'm not really sure what the benefit of that is, apart from code sharing.
> 
> The heavy lifting of populating the layers happens in the main thread, the main application rendering is happening there, too. Only composing a few layers would happen in the thread. Is that worth it? Especially in terms of OpenGL it means that you have to do swapbuffers twice, once for the FBO rendering in the thread (layer composition) and the as part of the main rendering cycle.

nits: we don't need swapbuffers twice. Rendering thread does not need swapbuffer. Rendering thread just draw into FBO.

> And just to make it clear: I am indeed very interested in making (2) and (3) easier to maintain, provided we don't regress in performance.

> > Although we need some effort to refactor, we can actually offer minimal support to (2) and (3) after that.
> 
> I do see the advantage of getting rid of TextureMapperTiledBackingStore, but I do wonder if the result is slower in the end and maybe more complex. No'am, what is your take on all this?
> 

I'm sure it is easier to maintain (2) and (3) after refactoring.

But you can concern performance issue. If refactoring affects performance badly, there can be major two reasons.
1. implementation issue of coordinated graphics
2. thread communication overhead

In the #1 case, we will solve because coordinated graphics is so important.
In the #2 case, we can implement single thread fallback like chromium. We can switch easily rendering loop between RunLoop and just Timer. (It can help debugging.)

IMO, coordinated graphics can be slower at the first painting time, but zooming, scrolling and animations are absolutely faster than WK1 TextureMapepr. I think we does not need to be afraid about performance.


> > In addition, this project is not for only improving (2) and (3) in Qt.
> > After that, we apply threaded coordinated graphics to GTK WK1 and WK2.
> 
> How do you plan to integrate with their application rendering? Also through an intermediate surface where just the layer composition happens in a separate thread?

Now I expect we composite into an intermediate surface (FBO) in a separate thread, and then blit the intermediate surface into Window's surface in the main thread.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > The heavy lifting of populating the layers happens in the main thread, the main application rendering is happening there, too. Only composing a few layers would happen in the thread. Is that worth it? Especially in terms of OpenGL it means that you have to do swapbuffers twice, once for the FBO rendering in the thread (layer composition) and the as part of the main rendering cycle.
> 
> I think later maybe we can do something like paint in the main thread to a QPaintBuffer / cairo_recording_surface, and do the actual painting to the buffer in the compositor thread.

Absolutely, it is our goal as well as chromium folk's goal.

> But I agree that right now in the Qt context we don't really offload too much to the compositor thread. also I'm not sure if in order to achieve this background painting we have to put 
> 
> > I do see the advantage of getting rid of TextureMapperTiledBackingStore, but I do wonder if the result is slower in the end and maybe more complex. No'am, what is your take on all this?
> > 
> From what I understood this project's goal is more about GTK, and making the compositor work in GTK the same way it does in Chromium, and as a byproduct the code would be more maintainable for Qt as well.
> If this project was just for code maintainability I would rather avoid this refactor.

Very valid concern. This project had started for GTK. and now for QT and GTK. I agree that the benefit for QT is a bit little and controversial.

We will continue to refactor coordinated graphics until the refactoring has its own value.
When we reach at the point that refactoring makes code more complex, we will discuss with you how to work.

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