New issue
Advanced search Search tips

Issue 692814 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

DirectRenderer shouldn't use SharedBitmapManager for render pass resources

Project Member Reported by danakj@chromium.org, Feb 15 2017

Issue description

Right now DirectRenderer goes thru ResourceProvider as a nice abstraction of GL vs Software resources.

This is the right thing to do for accessing resources sent in the frame. But for resources it allocates itself, it is extra overhead to require those resources be in shared memory since they are never going anywhere.

This forces SynchronousCompositorFrameSink to take a SharedBitmapManager to give to the Display for resourceless software mode. And makes software compositing less efficient everywhere.

There's 2 general ways to fix this:

1) Add a CreateResource() mode to ResourceProvider that gives a local resource. It wouldn't need to differ for GL but would for software.

2) Don't use ResourceProvider to allocate RenderPass resources directly. Go thru the DirectRenderer's subclass (GLRenderer or SoftwareRenderer). The GLRenderer could go to ResourceProvider. The SoftwareRenderer could use malloc. It would require not using "Resource" in the DirectRenderer and providing some other general type to be used there.
 
Currently the browser process's SharedBitmapManager actually allocates using new[], because nothing there needs to be shared cross-process (even browser compositor resources). But it would make sense to allow the ResourceProvider  to directly creating non-shared resources for the SynchronousCompositorFrameSink case.
Cc: xing...@intel.com

Comment 3 by danakj@chromium.org, Jan 16 2018

Status: Fixed (was: Available)
These don't use ResourceProvider anymore for renderpass resources.

Sign in to add a comment