Page MenuHomePhabricator

Bug 1579235 - Part 6 - Support an opaque/alpha native surface per slice.
ClosedPublic

Authored by gw on Feb 27 2020, 12:43 AM.

Details

Summary

Previously, a native compositor surface was considered to be
completely opaque, or completely translucent. This is due to
a limitation in how alpha is handled in the DirectComposition
API level.

With this patch, each picture cache slice maintains both an
opaque and translucent native surface handle. Tiles are assigned
to one of those surfaces based on their current opacity.

This is a performance optimization in some cases, since:

  • Even if part of a cache is translucent, opaque tiles can still participate in occlusion at the compositor level.
  • If a tile is changing from opaque to translucent, it now invalidates only that tile, rather than the entire surface.

The primary benefit of this patch is that it allows compositor
surfaces to be drawn sliced in between the opaque surface and
any overlay / alpha tiles.

Diff Detail

Repository
rMOZILLACENTRAL mozilla-central
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

gw created this revision.Feb 27 2020, 12:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 27 2020, 12:43 AM
phab-bot requested review of this revision.Feb 27 2020, 12:43 AM
phab-bot changed the visibility from "Custom Policy" to "Public (No Login Required)".
phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".
phab-bot removed a project: Restricted Project.

I think this should _strictly_ be as good or better in terms of performance, but let me know if you can see any issues with this.

Bert accepted this revision.Feb 27 2020, 1:10 AM

Is there an increase in native surface memory use from allocating both opaque and alpha?

This revision is now accepted and ready to land.Feb 27 2020, 1:10 AM
gw added a comment.Feb 27 2020, 1:15 AM

Is there an increase in native surface memory use from allocating both opaque and alpha?

There shouldn't be. Allocation of a native surface is minimal on both implementations. It should only be when tile(s) are added that there is backing GPU memory allocated, and that should be constant with the current usage.

gw updated this revision to Diff 235700.Feb 28 2020, 12:48 AM
gw updated this revision to Diff 236574.Mar 1 2020, 3:55 AM