For the context of this post,\u00a0it is assumed a ‘content_shell’ ChromeOS\u00a0GN build produced with the following commands:<\/p>\n
$ gn gen --args='target_os<\/strong>=\"chromeos\"\r\n use_ozone<\/strong>=true\r\n \u00a0ozone_platform_wayland<\/strong>=true\r\n use_wayland_egl<\/strong>=false\r\n ozone_platform_x11<\/strong>=true\r\n ozone_platform_headless<\/strong>=true\r\n ozone_auto_platforms<\/strong>=false' out-gn-ozone\r\n\r\n$ ninja -C out-gn-ozone blink_tests<\/pre>\nOzone at runtime<\/h3>\n
Looking at the\u00a0build\u00a0arguments above, one can foresee that the\u00a0content_shell <\/em>app will be able to run on the following Graphics backends: Wayland (no EGL), X11, and “headless” – and\u00a0it indeed is. This happens\u00a0thanks to\u00a0Chromium’s Graphics layer abstraction, Ozone<\/strong><\/a>.<\/p>\n
So, in order to run content_shell<\/em> app\u00a0on Ozone platform “bleh”, one simply does:<\/p>\n
$ out-gn-ozone\/content_shell --ozone-platform=\"bleh\"<\/pre>\nSimple no?\u00a0Well, yes .. and not as much.<\/p>\n
The way the desired\u00a0Ozone platform classes\/objects are\u00a0instantiated is interesting, involving c++ templates, GYP\/GN hooks, python generated code, and more. This post aims\u00a0to\u00a0detail the process some more.<\/p>\n
Ozone platform selection logic<\/h3>\n
Two methods kick off\u00a0OzonePlatform instantiation: ::InitializeForUI and ::InitializeForGPU<\/a>\u00a0. They both call ::CreateInstance(), which\u00a0is our starting point.<\/p>\n
This is how\u00a0simple it looks:<\/p>\n
63 void OzonePlatform::CreateInstance() {\r\n64 \u00a0 \u00a0 if (!instance_) {\r\n(..)\r\n69 \u00a0 \u00a0 \u00a0 \u00a0 std::unique_ptr<OzonePlatform> platform =<\/strong>\r\n70 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 PlatformObject<OzonePlatform>::Create();<\/strong>\r\n71\r\n72 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ TODO(spang): Currently need to leak this object.\r\n73 \u00a0 \u00a0 \u00a0 \u00a0 OzonePlatform* pl = platform.release();\r\n74 \u00a0 \u00a0 \u00a0 \u00a0 DCHECK_EQ(instance_, pl);\r\n75 \u00a0 \u00a0 }\r\n76 }\r\n<\/pre>\nEssentially, when\u00a0PlatformObject<T>::Create is ran (lines 69 and 70), it\u00a0ends up calling a method named Create{T}Bleh<\/strong>, where<\/p>\n
\n
- “T” is the template argument name, e.g. “OzonePlatform”.<\/li>\n
- “bleh” is the value passed to –ozone-platform command line parameter.<\/span><\/li>\n<\/ul>\n
For instance, in the case of .\/content_shell\u00a0–ozone-platform=x11<\/em>,\u00a0the method called would CreateOzonePlatformX11<\/em>, following the pattern\u00a0Create{T}<\/span>Bleh\u00a0<\/strong>(i.e. “Create”+”OzonePlatform”+”X11”).<\/p>\n
<\/h3>\n
The actual\u00a0logic<\/h3>\n
In order to understand how PlatformObject<\/em> class\u00a0works, lets start by\u00a0looking at its\u00a0definition\u00a0(ui\/ozone\/platform_object.h &\u00a0platform_internal_object.h):<\/p>\n
template <class T>\u00a0class PlatformObject {\r\n public:\r\n static std::unique_ptr<T> Create();\r\n};<\/pre>\n16 template <class T>\r\n17 std::unique_ptr<T> PlatformObject<T>::Create() {\r\n18 \u00a0 \u00a0 typedef typename PlatformConstructorList<T>::Constructor Constructor;\r\n19\r\n20 \u00a0 \u00a0 \/\/ Determine selected platform (from --ozone-platform flag, or default).\r\n21 \u00a0 \u00a0 int platform = GetOzonePlatformId();<\/strong>\r\n22\r\n23 \u00a0 \u00a0 \/\/ Look up the constructor in the constructor list.\r\n24 \u00a0 \u00a0 Constructor constructor = PlatformConstructorList<T>::kConstructors[platform];<\/strong>\r\n26 \u00a0 \u00a0 \/\/ Call the constructor.\r\n27 \u00a0 \u00a0 return base::WrapUnique(constructor());\r\n28 }\r\n<\/pre>\nIn\u00a0line 24\u00a0(highlighted above), the ozone platform runtime selection machinery actually happens. It\u00a0retrieves a Constructor<\/em>, which is a typedef for a PlatformConstructorList<T>::Constructor.<\/p>\n
By looking at the definition of\u00a0PlatformConstructorList<\/em> class (below), Constructor<\/em> is actually a pointer to a function\u00a0that returns a T*.<\/p>\n
14 template <class T>\r\n15 struct PlatformConstructorList {\r\n16 \u00a0 \u00a0 typedef T* (*Constructor)();\r\n17 \u00a0 \u00a0 static const Constructor kConstructors<\/strong>[kPlatformCount];\r\n18 };\r\n<\/pre>\nOk, so basically here is what\u00a0we know\u00a0this far:<\/p>\n
\n
- OzonePlatform::CreateInstance method calls\u00a0OzonePlatform<bleh>::Create<\/li>\n
- OzonePlatform<bleh>::Create picks up an\u00a0index<\/em> and\u00a0retrieves a\u00a0PlatformConstructorList<bleh>::Constructor (via kConstructor[index])<\/li>\n
- PlatformConstructorList<bleh>::Constructor is\u00a0a typedef to a function pointer that returns a bleh*.<\/em><\/li>\n
- (..)<\/li>\n
- This chain\u00a0ends up calling Create{bleh}{ozone_platform}()<\/li>\n<\/ol>\n
But wait!\u00a0kConstructors<\/em>, the\u00a0array of pointers to functions – that solves the\u00a0puzzle – is\u00a0not<\/strong> defined anywhere in src\/! \ud83d\ude42<\/p>\n
This is because its actual definition is part of some generated code triggered by\u00a0specific GN\/GYP hooks. They are:<\/p>\n
\n
- generate_ozone_platform_list<\/em>\u00a0which\u00a0generates out\/..\/platform_list.cc,h,txt<\/li>\n
- generate_constructor_list<\/em>\u00a0which\u00a0generates out\/..\/constructor_list.cc<\/em> though\u00a0generate_constructor_list.py<\/em><\/li>\n<\/ul>\n
In the end out\/..\/generate_constructor_list.cc<\/em> has the definition of\u00a0kConstructors.<\/em><\/p>\n
Again, in the specific case of the\u00a0given GN build arguments, kConstructors <\/em>would look like:<\/p>\n
template <> const OzonePlatformConstructor\r\nPlatformConstructorList<ui::OzonePlatform>::kConstructors<\/strong>[] = {\r\n &ui::CreateOzonePlatformHeadless,\r\n &ui::CreateOzonePlatformWayland,\r\n &ui::CreateOzonePlatformX11,\r\n};\r\n<\/pre>\n<\/h3>\n
Logic wrap up<\/h3>\n
\n
- GYP\/GN hooks are ran at build time, and generate\u00a0plaform_list.{txt,c,h} as well as constructor_list.cc files respecting ozone_platform_bleh<\/em> parameters.\n
\n
- constructor_list.cc has PlatformConstructorList<bleh>kConstructors<\/em>\u00a0actually populated.<\/li>\n<\/ul>\n<\/li>\n
- .\/content_shell –ozone-platform=bleh<\/em> is called<\/li>\n
- OzonePlatform::InitializeFor{UI,Gpu}()<\/li>\n
- OzonePlatform::CreateInstance()<\/li>\n
- PlaformObject<OzonePlatformBleh>::<\/em>Create()<\/li>\n
- PlatformConstructorList<bleh>::Constructor is retrieved – it is a pointer to a function stored in\u00a0PlatformConstructorList<bleh>::kConstructor<\/li>\n
- function is ran and an OzonePlatformBleh instance is returned.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Requisites For the context of this post,\u00a0it is assumed a ‘content_shell’ ChromeOS\u00a0GN build produced with the following commands: $ gn gen –args=’target_os=”chromeos” use_ozone=true \u00a0ozone_platform_wayland=true use_wayland_egl=false ozone_platform_x11=true ozone_platform_headless=true ozone_auto_platforms=false’ out-gn-ozone $ ninja -C out-gn-ozone blink_tests Ozone at runtime Looking at the\u00a0build\u00a0arguments above, one can foresee that the\u00a0content_shell app will be able to run on the following … Continue reading Understanding Chromium’s runtime ozone platform selection<\/span>