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

Issue 596893 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

content/common/*_mac depends on ui/gfx/transform.h which depends directly on skia

Project Member Reported by markdittmer@chromium.org, Mar 22 2016

Issue description

Current efforts to move content/common/gpu to gpu demand that code that's currently in the former location not depend on skia.

In addition to separating skia and non-skia ui/gfx/ipc (see https://bugs.chromium.org/p/chromium/issues/detail?id=596242), we need to eliminate dependencies:

content/common/gpu/*_mac -> ui/gfx/transform.h -> [[skia headers]]

Proposed solution:

1. Create an interface in content/common/gpu (to be later moved with the rest of content/common/gpu) that provides functionality required by content/common/gpu/*_mac

2. Make ui/gfx/transform implement the new interface
 

Comment 1 by piman@chromium.org, Mar 22 2016

I think it's ok to keep skia in content/common/gpu/ (except in content/common/gpu/client), basically for things that will end up in gpu/ipc/service. The skia requirement is for client-side (and common) things, that will need to be included in NaCl, but the service side is not intended to move to NaCl.
Just discussed this with fsamuel@ and I thik piman@ is right. The assumption that we can't depend on skia was an over-approximation from my previous attempt to move most of content/common/gpu (non-client) to gpu/ipc/service. Some of the stuff I tried to move should be in gpu/ipc/common, which links against nacl. The build errors arising from the skia/nacl conflict made me think that all code moving to gpu/ipc/* cannot depend on skia (which, as piman@ points out, is not the case for service code).

Seeing as the _mac code in question is service code, I believe that this is a spurious bug. Any further comments/discussion/clarification before I close?
It's not clear why the image transport (including Mac and friends) is in common -- yes, it is service.

In practice, the ca_layer_tree_mac.mm can-and-should be moved to ui/, since I hope to one day execute that code in the browser.
Blocking: -586365
Removing this as a blocker for 586365 but keeping it open for now.
Status: WontFix (was: Untriaged)
Marking this bug as won't fix.

Sign in to add a comment