Bug 101508 – [EFL][WK2] Add API to limit number of compositing layers for mobile devices.

• Component: WebKit EFL
• Status: RESOLVED INVALID

[Viatcheslav Ostapenko]

Mobile devices are not able big pages with big number of layers. 
Such pages should be display in non-composited mode on mobile devices.

[Viatcheslav Ostapenko]

Created attachment 172872 [details]
Layer limit patch.

[WebKit Review Bot]

Attachment 172872 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/rendering/RenderLayerCompositor.h:299:  The parameter name "layer" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/rendering/RenderLayerCompositor.cpp:1584:  More than one command on the same line in if  [whitespace/parens] [4]
Total errors found: 2 in 12 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Simon Fraser (smfr)]

Comment on attachment 172872 [details]
Layer limit patch.

Just counting layers is not the right way to limit resource use. You need to consider their backing store size. Also when you hit this limit you'r breaking page rendering, because your z-ordering will be incorrect, and you'll fail to make compositing layers for things like video and 3d that require it.

[Viatcheslav Ostapenko]

(In reply to comment #3)
> (From update of attachment 172872 [details])
> Just counting layers is not the right way to limit resource use. You need to consider their backing store size. 

Actually, just big number of small layers also could be a problem for a slow CPU/GPU device, but I agree that several relatively large layers is bigger problem.
I was going to do memory limit as a separate patch, but may be there is better approach to do this instead of 2 different limits?

>Also when you hit this limit you'r breaking page rendering, because your z-ordering will be incorrect, 

I don't get it. Can it render correctly on single layer like in case when compositing is switched off? So far pages I've tried display normally, just work slower if they have some animations.

> and you'll fail to make compositing layers for things like video and 3d that require it.

IMHO, if device cannot handle all layers on the page should we really care about fancy things like video and 3d? The target is just to be able to show page readable in somewhat degraded mode. A lot of things work much slower in this mode because require layer image/texture updates. Of course if video and even 3d work that would be great, but I don't think it can be done correctly in all cases. For example, if video has some overlay on top and page switches do degraded mode, than we do layer for video and overlay will stay behind the video.

[Noam Rosenthal]

(In reply to comment #4)
> (In reply to comment #3)
> I was going to do memory limit as a separate patch, but may be there is better approach to do this instead of 2 different limits?

Probably turn compositing off altogether in low memory conditions.

> >Also when you hit this limit you'r breaking page rendering, because your z-ordering will be incorrect, 
> 
> I don't get it. Can it render correctly on single layer like in case when compositing is switched off? So far pages I've tried display normally, just work slower if they have some animations.

Problem is that if you create a compositing layer, a layer overlapping it and on top also has to be composited, otherwise it would appear in the wrong z-order. You should look at RenderLayerCompositor::requiresCompositingForIndirectReason and friends.

> 
> > and you'll fail to make compositing layers for things like video and 3d that require it.
> 
> IMHO, if device cannot handle all layers on the page should we really care about fancy things like video and 3d? The target is just to be able to show page readable in somewhat degraded mode. A lot of things work much slower in this mode because require layer image/texture updates. Of course if video and even 3d work that would be great, but I don't think it can be done correctly in all cases. For example, if video has some overlay on top and page switches do degraded mode, than we do layer for video and overlay will stay behind the video.

That's exactly why the layer-limit approach is broken. If you don't want "fancy" video and 3d you should just disable them and not create broken layer configurations.

I would say that perhaps the way to go about this is to dynamically modify the allowedCompositingTriggers on your ChromeClient based on memory conditions.

[Viatcheslav Ostapenko]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > I was going to do memory limit as a separate patch, but may be there is better approach to do this instead of 2 different limits?
> 
> Probably turn compositing off altogether in low memory conditions.
> 
> > >Also when you hit this limit you'r breaking page rendering, because your z-ordering will be incorrect, 
> > 
> > I don't get it. Can it render correctly on single layer like in case when compositing is switched off? So far pages I've tried display normally, just work slower if they have some animations.
> 
> Problem is that if you create a compositing layer, a layer overlapping it and on top also has to be composited, otherwise it would appear in the wrong z-order. You should look at RenderLayerCompositor::requiresCompositingForIndirectReason and friends.
> 
> > 
> > > and you'll fail to make compositing layers for things like video and 3d that require it.

Basically, that's what patch does. It allows only root layer. It counts total number of layers at the beginning and if the number is bigger than limit it disables compositing of all layers. 

> > IMHO, if device cannot handle all layers on the page should we really care about fancy things like video and 3d? The target is just to be able to show page readable in somewhat degraded mode. A lot of things work much slower in this mode because require layer image/texture updates. Of course if video and even 3d work that would be great, but I don't think it can be done correctly in all cases. For example, if video has some overlay on top and page switches do degraded mode, than we do layer for video and overlay will stay behind the video.
> 
> That's exactly why the layer-limit approach is broken. If you don't want "fancy" video and 3d you should just disable them and not create broken layer configurations.

Is there way to dynamically disable 3d and video for current page?

> I would say that perhaps the way to go about this is to dynamically modify the allowedCompositingTriggers on your ChromeClient based on memory conditions.

Thanks, I'll check it.