This bug is to catch all remaining surface IDs cleanups. Here are some I've identified so far:
1. SurfaceId::is_null() => is_valid(). I've found that checks for "is_null()" really want to know, is this surface ID valid and ready for use or not? It's not checking "are all fields of the surface ID null". For example FrameSinkId may be set, but LocalFrameId may be null and code really cares about validity not nullness.
2. Use surface ID in fewer places. There are few good reasons to use SurfaceId directly now, we should use FrameSinkId or LocalFrameId more directly. E.g.
DirectCompositorFrameSink has a FrameSinkId, but Display::SetSurfaceId is still there. However, Display's FrameSinkId should never change. Thus, Display should take in a FrameSinkId at construction and Display::SetSurfaceId => Display::SetLocalFrameId.
3. It's really weird, unintuitive and brittle for SurfaceManager::RegisterSurfaceFactoryClient to be callable from anywhere. Now that SurfaceFactory is tied to a single FrameSinkId, RegisterSurfaceFactoryClient/UnregisterSurfaceFactoryClient should happen INSIDE SurfaceFactory. In some cases we create and destroy SurfaceFactories a bunch. I'm not sure yet why we do that (clear returned resources maybe?) but we should try not to to simplify logic. Wherever we call "RegisterSurfaceFactoryClient", we should just create a SurfaceFactory.
Comment 1 by staraz@chromium.org
, Oct 17 2016