New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 875110 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
█ trchen@chromium.org
pdr@chromium.org
enne@chromium.org
chrishtr@chromium.org
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 471333



Sign in to add a comment

[Blink/SPv2] Directly composited images?

Project Member Reported by trchen@chromium.org, Aug 16 
SPv1 has an optimization to use PictureImageLayer to draw an image if an image element without box decoration is composited.

SPv2 doesn't have corresponding code path yet, it always uses the regular ImagePainter code path.

Is this really needed? It seems to be introduced during very early WebKit days: https://github.com/WebKit/webkit/commit/ce3a4e007442d84161deebc1773b079792589c71#diff-fd33019873bcd74792a6d9b9aa8326de
And the rationale doesn't apply to us anyway.

"""When using hardware compositing, some images can be directly
rendered by the hardware - no need to draw them into a separate
context, therefore saving memory."""

As far as I can tell, PictureImageLayer is only a thin wrapper on top of PictureLayer, and its PictureLayerImpl still creates the tiles thus making an extra copy. The only difference is that raster scale will be snapped to power of 2 through a flag.

I feel supporting this code path already introduced a lot of hassle in BGPT and have negative effect to code health. Maybe we should drop it from SPv2, or even BGPT.

Comment 1 by enne@chromium.org, Aug 17 

It's not just memory.  It's also smarter about rerasterization when bounds change.  It's also cheaper to decode at scale=1 than it is to do the scaling up.

For software raster, this feature has been helpful in a number of use cases.  This probably doesn't do as much for gpu raster these days.  My hope was that being smarter about when and if to create such layers was something that could come with slimming paint once layerization decisions moved to the compositor thread.

I think it would cause regressions to replace PictureImageLayer with just PictureLayer.  I think would be ok in the far future to replace PictureImageLayer by not compositing that layer in the first place if we are using gpu raster.

Comment 2 by schenney@chromium.org, Aug 17

Owner: trchen@chromium.org
Status: Assigned (was: Untriaged)
I'm assigning this to drive toward a decision on what to do for SPv2. We shouldn't let it languish.

Comment 3 by trchen@chromium.org, Sep 14

Owner: pdr@chromium.org
I'm leaving the team, thus re-assigning.

Comment 4 by pdr@chromium.org, Today (15 hours ago)

Blocking: 471333
Owner: ----
Status: Available (was: Assigned)
Marking as blocking the CAP metabug.

There has been some discussion of removing this optimization entirely.
►

Sign in to add a comment