Move Mus into chrome's process when running with --mus.

services/ui/service.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef SERVICES_UI_SERVICE_H_
 #define SERVICES_UI_SERVICE_H_
 
 #include <stdint.h>
 
 #include <map>
@@ skipping 45 matching lines @@
 class InputDeviceController;
 class PlatformEventSource;
 
 namespace ws {
 class WindowServer;
 }
 
 class Service : public service_manager::Service,
                 public ws::WindowServerDelegate {
  public:
-  Service();
+  // |resource_runner| is the task runner for the thread which can be used to
+  // load resources. Used when UI Service is run inside a Window Manager's
+  // process. When UI Service is run in a separate process, resource_runner
+  // should be null, and resources are loaded on the UI Service's thread.
+  Service(scoped_refptr<base::SingleThreadTaskRunner> resource_runner);

[sky, 2017/06/19 21:25:47]

Rather than having mus deal with the different embedding schemes could we
instead supply the set of cursors mus needs to the constructor? I'm thinking of
a key/value map of all the cursors it would need.

[Elliot Glaysher, 2017/06/19 21:46:43]

This sounds significantly better than having a wrapper proxy class.

Assuming your problems are with accessing the ResourceBundle, you could create
your own CursorLoader instance which takes the raw bitmaps key/value pair wise
as sky@ suggested. You'll need to lazily perform the scaling and rotation
yourself (see how cursor_loader_ozone.cc calls into cursor_util.cc, especially
GetImageCursorBitmap() and friends), but that should be entirely doable.

(If you're having threading problems with Ozone instead, that's going to be much
more difficult.)

[mfomitchev, 2017/06/19 21:50:19]

I considered this, but it would mean pre-loading and storing cursor resources
for all the possible display configurations (currently that just means scale
factors), which seems a bit wasteful. 
Additionally, we'd have to re-write cursor loaders for all the platforms to make
use of these pre-cached resources, and I thought it would be nice to avoid
tinkering with code in base/ too much. We could also write new resource loader
wrapper for Mus, but that's not much different from what we are doing here.

[sky, 2017/06/20 16:07:09]

I don't have a good feel for how many cursors and display configurations that
are supported. Is this on the order of tens of images, or hundreds? If it's
closer to hundreds, then I agree with you. If it's closer to 10-20(ish) then
preloading seems better.

[mfomitchev, 2017/06/20 17:00:42]

Ok. I think we have just two cursor sets right now - normal, and large. Each
contains 32 cursor bitmaps, plus there's 2 animated cursors which are currently
shared, but should be duplicated according to a comment.

Another potential concern with preloading is Windows. It doesn't have cursor
load functions implemented (CursorLoaderWin::LoadImageCursor), it only loads
cursors when they are set - I am not sure if there is some subtle reason for
this, or this was just an accidental omission. Do you happen to know?

If we go the preload route, I think the way to go would be to teach cursor code
in base to preload all cursor resources and operate on preloaded resources
rather than operating on the resource bundle. Does this sound reasonable? The
existing code loads cursor bitmaps, and then scales/rotates them in the same
function, e.g. see GetImageCursorBitmap. I think we'd have to break that apart
so that we don't need to duplicate code. 

I am thinking we can change the existing Cursor Loaders (ozone, win, and x11) to
support preloading cursors for all display configurations and then using that.
We can then pass a cursor loader instance to the UI Service constructor.

   ~Service() override;
 
  private:
   // Holds InterfaceRequests received before the first WindowTreeHost Display
   // has been established.
   struct PendingRequest;
   struct UserState;
 
   using UserIdToUserState = std::map<ws::UserId, std::unique_ptr<UserState>>;
 
+  bool in_process() { return resource_runner_ != nullptr; }
+
   // Attempts to initialize the resource bundle. Returns true if successful,
   // otherwise false if resources cannot be loaded.
   bool InitializeResources(service_manager::Connector* connector);
 
   // Returns the user specific state for the user id of |remote_identity|.
   // Service owns the return value.
   // TODO(sky): if we allow removal of user ids then we need to close anything
   // associated with the user (all incoming pipes...) on removal.
   UserState* GetUserState(const service_manager::Identity& remote_identity);
 
@@ skipping 66 matching lines @@
   std::unique_ptr<ui::PlatformEventSource> event_source_;
   using PendingRequests = std::vector<std::unique_ptr<PendingRequest>>;
   PendingRequests pending_requests_;
 
   UserIdToUserState user_id_to_user_state_;
 
   // Provides input-device information via Mojo IPC. Registers Mojo interfaces
   // and must outlive |registry_|.
   InputDeviceServer input_device_server_;
 
+  scoped_refptr<base::SingleThreadTaskRunner> resource_runner_;
   bool test_config_;
 #if defined(USE_OZONE)
   std::unique_ptr<gfx::ClientNativePixmapFactory> client_native_pixmap_factory_;
 #if defined(OS_CHROMEOS)
   std::unique_ptr<InputDeviceController> input_device_controller_;
 #endif
 #endif
 
   // Manages display hardware and handles display management. May register Mojo
   // interfaces and must outlive |registry_|.
   std::unique_ptr<display::ScreenManager> screen_manager_;
 
   IMERegistrarImpl ime_registrar_;
   IMEServerImpl ime_server_;
 
   std::unique_ptr<discardable_memory::DiscardableSharedMemoryManager>
       discardable_shared_memory_manager_;
 
   service_manager::BinderRegistry registry_;
 
   // Set to true in StartDisplayInit().
   bool is_gpu_ready_ = false;
 
   DISALLOW_COPY_AND_ASSIGN(Service);
 };
 
 }  // namespace ui
 
 #endif  // SERVICES_UI_SERVICE_H_