597806 - Fennec should use X as little as possible

Status: RESOLVED DUPLICATE of bug 597336

(Core :: Graphics, defect)

Description

[Oleg Romashin (:romaxa)]

I found recently that X rendering is not gonna work.

Stuart's idea of rendering everything on X side, binding X surfaces to GL textures, and rendering plugins with X, this all will not work... because  we are pushing too many rendering tasks on X side... and it is not possible to do fast scrolling on chrome side with X and prepare next content update at the same time because all these things happens in one "X" process.

We should render everything locally with pixman or any other process bounded rasterizer ... and then just blt ready images to X.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you be more specific about what you did to arrive at this conclusion? Did you profile some workload and find that X is the bottleneck? What was the workload and what can you tell us about the profile?

Comment 2

[Oleg Romashin (:romaxa)]

Problem is that pixman  is usually slow, and not optimized everywhere....
And we are trying to use on N900 Gtk Xorg pixman as primary rasterizer.

With current fennec/remote layers(using X) we have problem with single threaded X server... We are using X-server (Xrender->pixman) to prepare shadowLayerChild content, and with this we are slowing down whole XServer process and see rendering lags screen...
we've created multi-process environment and failing with single process rendering compositor.

This problem not visible on Fennec Qt port (raster mode enabled by default on N900 and qt works with images), also this problem not visible on Android (only images used there), and MicroB browser on N900 rendering all content layout data with gfxImageSurface....
But problem visible on GTK N900 Fennec, where we are rendering all things with X/XRender and overloading Xorg process with content rendering operations.

so for GTK we have two options:
1) render child with image and XSHmPuthimage to Parent process... and on parent process continue use X surfaces
2) Switch everything to Images, render all images(layers) to SHM memory (screen size image), and then do XSHMPutimage to GDK window (similar what microb does) and qt raster backend

with option 1) we still can use X-HandleEvent for plugins... but that require Plugin-Show implementation across the processes (send plugin X-surface directly to Chrome process from plugin child process)

with option 2) we must switch plugins to image rendering NPAPI (on maemo 5 use existing proposal), on maemo6 use new NPAPI image rendering.


Please don't start here discussion about GL acceleration.... that will just make things even more complicated... and not gonna fix this problem.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

How about XRender? Why don't these devices have any XRender acceleration?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I hate X bugs.

(In reply to comment #2)
> so for GTK we have two options:
> 1) render child with image and XSHmPuthimage to Parent process... and on parent
> process continue use X surfaces
> 2) Switch everything to Images, render all images(layers) to SHM memory (screen
> size image), and then do XSHMPutimage to GDK window (similar what microb does)
> and qt raster backend
> 
> with option 1) we still can use X-HandleEvent for plugins... but that require
> Plugin-Show implementation across the processes (send plugin X-surface directly
> to Chrome process from plugin child process)

I'm not sure why that's needed. Can't the content process just set up an ImageLayer with an X surface, so we create a shadow layer for that in the chrome process? That shouldn't require the plugin process to talk directly to the compositor.

Comment 5

[Oleg Romashin (:romaxa)]

Yep, plugin will call just Show(new, back), and content forward this call to Chrome... and so "new" X-Surface will appear on Chrome process.

But anyway for option 1, we need to make something to render content into image surface, and then push it into chrome X-Surface.... in this case we should allocate 3 surfaces (front, back X + temporary image)....

Comment 6

[Oleg Romashin (:romaxa)]

(In reply to comment #3)
> How about XRender? Why don't these devices have any XRender acceleration?

Because we are still in 21-st century... not in 23 or 24... ;)

Comment 7

[Oleg Romashin (:romaxa)]

Fennec has been switched to image rendering and don't use XRender anymore.