It started with my need to debug Chromium’s implementation of OpenXR. I wanted to understand how Chromium interfaces with OpenXR APIs. However, I noticed that only the Android and Windows ports of Chromium currently support OpenXR bindings. Since I needed to debug a desktop implementation, Windows was the only viable option. Additionally, I did not have access to a physical XR device, so I explored whether a simulator or emulator environment could be used to test WebXR support for websites.

Understanding WebXR and OpenXR

Before diving into implementation details, it’s useful to understand what WebXR and OpenXR are and how they differ.

WebXR is a web standard that enables immersive experiences, such as Virtual Reality (VR) and Augmented Reality (AR), in web browsers. It allows developers to create XR content using JavaScript and run it directly in a browser without requiring platform-specific applications.

OpenXR is a cross-platform API standard developed by the Khronos Group, designed to unify access to different XR hardware and software. It provides a common interface for VR and AR devices, ensuring interoperability across different platforms and vendors.

The key difference is that WebXR is a high-level API used by web applications to access XR experiences, whereas OpenXR is a low-level API used by platforms and engines to communicate with XR hardware. WebXR implementations, such as the one in Chromium use OpenXR as the backend to interact with different XR runtimes.

Chromium OpenXR Implementation

Chromium’s OpenXR implementation, which interacts with the platform-specific OpenXR runtime, is located in the device/vr/ directory. WebXR code interacts with this device/vr/ OpenXR implementation, which abstracts WebXR features across multiple platforms.

WebXR ---> device/vr/ ---> OpenXR API ---> OpenXR runtime

Installing OpenXR Runtime

To run OpenXR on Windows, you need to install an OpenXR runtime. You can download and install OpenXR Tools for Windows Mixed Reality from the Microsoft App Store:

If it is not available on your machine, you can enable it from the OpenXR Runtime tab in the application.

Installing Microsoft Mixed Reality Simulator

To set up a simulated environment for WebXR testing, follow these steps:

1. Install Mixed Reality Portal from the Microsoft App Store.
2. Follow the official Microsoft guide on enabling the Mixed Reality simulator: Using the Windows Mixed Reality Simulator

If you encounter hardware compatibility errors, refer to the troubleshooting steps in the guide below.

https://www.thewindowsclub.com/disable-hardware-requirement-checks-for-mixed-reality-portal

Connecting Chromium to OpenXR Implementation

Chromium provides a flag to select the OpenXR implementation.

1. Open Chrome and navigate to:

   chrome://flags/#webxr-runtime
   

2. Set the flag to OpenXR.

This enables Chromium to use the OpenXR runtime for WebXR applications.

Launch WebVR application

Launch chromium and Open : https://immersive-web.github.io/webxr-samples/immersive-vr-session.html

CallStack

When we call navigator.xr.requestSession("immersive-vr"); from Javascript, below call stack get triggered.

Conclusions

With this setup, you can explore and debug WebXR applications on Windows even without a physical VR headset. The combination of Chromium’s OpenXR implementation and Microsoft’s Mixed Reality Simulator provides a practical way to test WebXR features and interactions.

If you’re interested in further experimenting, try developing a simple WebXR scene to validate your setup! Additionally, we plan to post more about Chromium’s architecture on OpenXR and will link those posts here once they are ready.

CEFClient and CEFSharp

The base CEF framework includes support for the C and C++ programming languages. Also it provides a test applications to demonstrate its functionality. CEFClient, a one of the C++ test application, serves this purpose.

CEF provides CAPI bindings to enable application development across various programming languages. For integrating the CEF framework with .NET, you should explore CEFSharp. It is a C# application that leverages the CEF open source project, allowing developers to create applications in C#.

CEFSharp(C#)
            \  CAPI 
              -------> CEF(C++) ------> Chromium(C++)
            /
CEFClient(C++)

What is the sandbox?

As mentioned in documentation of sandbox in Chromium repository,

The sandbox is a C++ library that allows the creation of sandboxed processes — processes that execute within a very restrictive environment. The only resources sandboxed processes can freely use are CPU cycles and memory. For example, sandboxes processes cannot write to disk or display their own windows. What exactly they can do is controlled by an explicit policy. Chromium renderers are sandboxed processes.

Understanding Sandboxing in CEF

Since CEF uses Chromium internally, we decided to investigate how sandboxing is implemented by examining Chromium’s source code. Our findings revealed that the sandbox is designed to be versatile, with no hard dependencies on the Chromium browser itself, making it usable with other applications.

CEF prepares a static library using the existing sandbox implementation in the Chromium repository and links it to the main application. This process enables the sandbox functionality in CEF applications. For more detailed information, refer to the sandbox_win.cc file in the CEF repository.

if (is_win) {
  static_library("cef_sandbox") {
    sources = [ "libcef_dll/sandbox/sandbox_win.cc" ]
    include_dirs = [ "." ]
    deps = [ "libcef/features", "//sandbox" ]
  }
}

Implementing Sandboxing in CEFClient

CEFClient achieves a sandboxing by linking to cef_sandbox library

  executable("cefclient") {
      deps += [
        ":cef_sandbox",
      ]

In the CEFClient application, we need to create a sandbox object and pass it to CEF, which then forwards it internally to Chromium to configure the sandbox.

  CefScopedSandboxInfo scoped_sandbox;
  sandbox_info = scoped_sandbox.sandbox_info();
  ...
  // Initialize the CEF browser process.
  if (!context->Initialize(main_args, settings, app, sandbox_info)) {
    return 1;
  }

The following call stack illustrates how CEFClient code calls into CEF, ultimately transitioning into the Chromium environment to configure the sandbox.

The CEF test application (CEFClient) successfully launches a sandboxed CEF, which is verified by loading the chrome://sandbox URL.

Why C# Applications Cannot Use Sandboxed CEF ?

As we have seen above, for C++ applications it is possible to use sandboxing but C# application can not use sandboxed CEF. But why ?

To achieve effective sandboxing in your CEF application, ensure that you link the cef_sandbox.lib static library. This linking must be done specifically to the main process of the application. While C++ applications can directly link static libraries without issue, C# applications do not support static linking of libraries.

Static library means that the library is going to be merged with application. This concept doesn't exist in .NET as .NET supports only dynamic link libraries

If you attempt to create a DLL for the cef_sandbox code and link it dynamically to your application, the Chromium sandbox code will detect this and fail with the error SBOX_ERROR_INVALID_LINK_STATE. Therefore, static linking of the sandboxing code to the main application is mandatory for sandbox functionality.

  // Attempt to start a sandboxed process from sandbox code hosted not within
  // the main EXE. This is an unsupported operation by the sandbox.
  SBOX_ERROR_INVALID_LINK_STATE = 64,

Conclusion

While sandboxing is a powerful feature available for C++ applications using CEF, it is not feasible for C# applications due to the inherent differences in how these languages operate within the system. The managed environment of C# introduces limitations that make it impossible to integrate the same level of sandboxing as in C++. Consequently, C# applications cannot leverage sandboxed CEF using the existing setup.

Future study

To enable sandboxing in C# applications, we may need to modify the .NET runtime (which is written in C++) to support sandboxing. This would involve linking the cef_sandbox library directly to the runtime. The .NET Core runtime includes several executables/libraries that act as the main entry point for code execution, typically referred to as the “host”. These host executables can be customized as needed.

For example, when you run the apphost executable, it initializes the .NET Core runtime and starts your application. Creating a sandbox object in the apphost and passing it to the application might help address sandboxing for C# applications. However, this approach has not been tested, so its effectiveness cannot be confirmed without further exploration and modification of the C# language runtime.

References

• https://stackoverflow.com/questions/1590337/using-the-google-chrome-sandbox
• https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md
• https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox_faq.md

You can learn more about LaCrOS in my previous blog. From the above table, the difference in filesystem was the first suspect. Squashfs is a compressed read-only file system for Linux.

To emulate the first launch, all caches are cleared using drop_caches as below. echo 3 > /proc/sys/vm/drop_caches

How to measure a file system read time?

For investigation and testing/benchmarking, sequential read requests are emulated using a dd command and random read requests are emulated using fio(Flexible IO Tester)

For sequential read, B1 took around 92MB/s while B2 took 242MB/s.(Higher read speed means faster). Its a huge difference. ext4 is faster than squashfs.

localhost ~ # echo 3 > /proc/sys/vm/drop_caches
localhost ~ # time dd
if=/run/imageloader/lacros-dogfood-dev/99.0.4824.0/chrome of=/dev/null bs=4096
43910+1 records in
43910+1 records out
179859368 bytes (180 MB, 172 MiB) copied, 1.93517 s, 92.9 MB/s

real    0m1.951s
user    0m0.020s
sys 0m0.637s

localhost ~ # echo 3 > /proc/sys/vm/drop_caches
localhost ~ # time dd if=/usr/local/lacros-chrome/chrome of=/dev/null bs=4096
43910+1 records in
43910+1 records out
179859368 bytes (180 MB, 172 MiB) copied, 0.744337 s, 242 MB/s

real    0m0.767s
user    0m0.056s
sys 0m0.285s

As Squashfs is a compressed file system, it first uncompresses the data and then performs a read. So definitely it’s going to be slower than ext4 but the difference(242 -92) was huge and unacceptable.

Can we do better?

The next step was to find some tools that could provide more information.

• strace - Linux utility to find out system calls that take more time or have blocking IO. But couldn’t get much information out of this analysis.
• iostat - This provides more insight information for input/output

$echo 3 > /proc/sys/vm/drop_caches && iostat -d -tc -xm 1 20

After running this command for both B1 and B2, it appears that B1 is not merging read requests. In other words, rrqm/s and %rrqm values are ZERO. Refer man-iostat

%rrqm The percentage of read requests merged together before being sent to the device.

rrqm/s The number of read requests merged per second that were queued to the device.

The data to be read is scattered in different sectors of a different block. As a result of scattering, the read requests were not merged, so there could be a lot of read requests down to the block device.

Next step was to find out who is responsible for merging read requests.

IO scheduler

IO scheduler optimizes disk access requests by merging I/O requests to similar locations on disk. To get the current IO scheduler for a disk-device

$/sys/block/<disk device>/queue/scheduler

for B1,

localhost ~ # cat /sys/block/dm-1/queue/scheduler 
none

For B2, it uses the bfq scheduler

localhost ~ # cat /sys/block/mmcblk0/queue/scheduler 
mq-deadline kyber [bfq] none

As you can notice, B1 does not have scheduler. For B2, scheduler is bfq(Budget Fair Queueing).

SUSE and IBM has good documentation about IO scheduling.

It has been found so far that there are differences between file systems, read request merge patterns, and IO schedulers. But there is one more difference which we havent noticed yet.

If you look at how B1 is mounted, you will see that we are using a virtual device.

localhost ~ # df -TH
Filesystem  Type      Size  Used  Avail  Use%  Mounted on
/dev/dm-1   squashfs  143M  143M      0  100%  /run/imageloader/lacros-dogfood-dev/99.0.4824.0

A twist in my story

For B1, we are not directly communicating with the block device instead the requests are going through a virtual device using a device mapper. As you might have noticed above, dm-1 device mapper virtual device is used by B1.

Read more about a device-mapper and refer to the diagram on wikipedia page.

We are using a dm-verity as a virtual device.

Device-Mapper’s “verity” target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API. This target is read-only.

From a security point of view, it makes sense to host your executable binary to a read-only files system that provides integrity checking.

There is a twist in that dm-verity does not have a scheduler, and scheduling is delegated to the scheduler of the underlying block device. The I/O will not be merged at the device-mapper layer, but at an underlying layer.

Several layers are different between B1 and B2, including partition encryption(dm-verity) and compression(squashfs).

In addition, we found that B1 defaults to using --direct-io

What is DIRECT IO ?

Direct I/O is a feature of the file system whereby file reads and writes go directly from the applications to the storage device, bypassing the operating system read and write caches.

Although direct I/O can reduce CPU usage, using it typically results in the process taking longer to complete, especially for relatively small requests. This penalty is caused by the fundamental differences between normal cached I/O and direct I/O.

Every direct I/O read causes a synchronous read from the disk; unlike the normal cached I/O policy where the read may be satisfied from the cache. This can result in very poor performance if the data was likely to be in memory under the normal caching policy.

Is it possible to control how many read requests are made?

We decided to go deeper and analyze the block layer. In the block layer the request queue is handled, and I/O scheduling is done. To see how the flow of IO goes through the block layer, there is a suit of tools consisting of

• blktrace (tracing the IO requests through the block layer),
• blkparse (parsing the output of blktrace to make it human readable),
• btrace (script to combine blktrace and blkparse, and
• btt (a blktrace output post-processing tool)), among others.

Below is the result of block-level parsing.

For B1,

For B2,

• Number of read requests(N) are more for B1 than B2.
  • For B1, N = 94883 (partition with squashfs + dm-verity)
  • For B2, N = 76171 (ext4 partition)
• Average D2C time for B1 is more than twice that of B2 (0.000176883 > 2*0.000067955).

D2C time: the average time from when the actual IO was issued to the driver until is completed (completion trace) back to the block IO layer.

--d2c-latencies option: This option instructs btt to generate the D2C latency file. This file has the first column (X values) representing runtime (seconds), while the second column (Y values) shows the actual latency for command at that time (either Q2D, D2C or Q2C).

FIO(Flexible IO Tester)

Up until now, all analysis has been performed using a dd which emulate sequential read requests.

Read access pattern also affects a IO performace so to emulated a random IO workloads tools like FIO is useful.

When you specify a --size, FIO creates a file with filename and when you don’ specify it FIO reads form a filename.

We are testing an existing chrome binary without providing its size.

localhost~# fio --name=4k_read --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --norandommap --filename=<dir>/chrome

Hotspots

A “hotspot” is a place where the app is spending a lot of time. After performing above analysis, find those areas and speed them up. This is easily done using a profiling tool like It has been found so far that there are differences between file systems, read request merge patterns, and IO schedulers. But there one more difference which we havent noticed yet.

For optimal performance,

• reduce the number of requests (N)
  • by tuning the blocksize of the filesystem(squashfs) of the partition
• reduce the time taken to process each request(D2C)
  • by tuning a compression algorithm used by squashfs filesystem
  • by tuning a hashing function used by dm-verity

Tuning a blocksize

Block is a continuous location on the hard drive where data is stored. In general, FileSystem stores data as a collection of blocks. When the block size is small, the data gets divided into blocks and distributed in more blocks. As more blocks are created, there will be more number of read requests.

Squashfs compresses files, inodes, and directories, and supports block sizes from 4 KiB up to 1 MiB for greater compression.

We experimented with different block sizes of 4K, 64K, 128K, 256K. As the block size is increasing, the read speed for DD is increasing. We have chosen 128K.

mksquashfs /tmp/squashfs-root /home/chronos/cros-components/lacros-dogfood-dev/100.0.4881.0/image.squash.test.<block-size> -b <block-size>K

Tuning a compression algorithm

Squashfs supports different compression algorithms. mksquashfs command has the option -comp <comp> to configure the compression algorithm. There are different compressors available:

• gzip (default)
• lzma
• lzo
• lz4
• xz
• zstd

mksquashfs /tmp/squashfs-root /home/chronos/cros-components/lacros-dogfood-dev/100.0.4881.0/image.squash.test.<block-size> -b <block-size>K -comp gzip

Tuning a hashing algorithm

This is related to dm-verity. dm-verity decrypt the read request. It uses different hashing algorithms.

• sha256 (default)
• sha224
• sha1
• md5 We can use hardware implementation of the above algorithms to speed up things.

Conclusion

The purpose of this blog post is to demonstrate how to identify the hotspot and how to explore different parameters affecting the system’s performance. It was an interesting experience and I learned a lot. By sharing all the details about how the problem was broken down and improved, I hope others can learn something as well. As a result of playing around with the various combinations of parameters such as blocksize, compression, and direct-io, we have decided to go with the following configuration.

1. For Filesystem,
   • Blocksize : Changed from 4K to 128K
   • Compression algorithm : Changed from gzip to xz
   • direct-io : Changed from on to off
2. dm-verity :
   • Hashing algorithm : Currently it used sha256. Either use hardware implementation of sha256 or switch to other algorithm.

Your first step should be to identify your current stack and then analyze each layer of your file system stack using the available tools and optimize them. The information provided in this blog may be helpful to you in deciding what to do about your own performance issues. You can get it touch with me if you need any help.

Igalia has been collaborating with Google on the LaCrOS project for over a year and has presented updates of the LaCrOS project in the last two BlinkOns.

See ours lightning talk during BlinkOn13 , and our update from BlinkOn14

What is LaCrOS ?

For the unfamiliar , the LaCrOS project decouples the Chrome browser from the Chrome OS window manager and system UI. The name comes from Linux And ChRomeOS.

But, why do we need to do that ? Let’s jump to more details.

Why LaCrOs ?

Previously, ChromeOS and Chrome Browser shared the same window manager and system UI binaries, making it difficult for Chrome Browser alone to be updated on Chromebook devices.

This means, when a ChromeOS device is updated, only then the Chrome Browser is updated. It might be frustrating for someone who frequently switches from the latest desktop browser to a browser on ChromeOS.

LaCrOS is Google’s solution to this problem. It allows browser on ChromeOS to update independently of the operating system. Now, old chromebook devices also can have the latest Chrome Browser.

Separating the browser from the OS itself allows the end user to update the browser independently as we do for other devices like desktop, mobile.

On Chrome OS, the system UI (including the Ash Window Manager, login screen, etc) and the Web Browser are included in the same binary. LaCrOS separates this functionality into two binaries. Both of these binaries are built from the same chromium git repository, but they might have different versions. This means, Web Browser and ChromeOS can have different versions and will be updated separately.

Some of the key LaCrOS components are ChromeOS’ built-in Wayland Compositor (Exo) and the native Linux Wayland support (on top of Ozone). As part of the project, Linux Wayland is being enhanced to implement ChromeOS specific functionality so that the a newly created browser acts like a Web Browser under ChromeOS.

This new browser which uses Linux Wayland support underneath to communicate with ChromeOS is called a LaCrOS(Linux And ChRomeOS).

In terms of wayland terminology, a LaCrOS-Chrome is a wayland-client and Exo is a wayland-server.

LaCrOS development involves both client and server code changes. ChromeOS implements handlers for requests coming from LaCrOS Browser, and LaCrOS Browser implements handlers for events coming from ChromeOS.

What is Ash-Chrome ?

Ash-Chrome is the default browser of ChromeOS which is tightly coupled with ChromeOS. For client-server architecture, Ash-Chrome is often referred as a server and used as a synonymous to ChromeOS or Exo.

LaCrOS client request a information from a Ash-Chrome server.

What is Exo ?

Exo(or Exosphere) is a wayland server implementation. LaCrOS is one of the client of Exo. There are other clients of Exo which includes ARC++(Android Apps on ChromeOS) and Crostini (Linux apps on Chrome OS).

A simplified LaCrOS Architecture

In the above diagram, LaCrOS Browser communicates with ChromeOS(Ash-Chrome) using a wayland protocol. LaCrOS uses various wayland protocols

• Official wayland protocols - These are developed by the Wayland community and well known desktop environments.
• Non-official wayland protocols - These protocols are specific to ChromeOS.

Exo is a wayland server and it supports both the official and non-official wayland protocols. Just for an example, aura_shell is a non-official protocol which allows the LaCrOS browser to support the ChromeOS specific features like snapping a window and many more.

Implementation of LaCrOS is inspired from Chrome on desktop linux. My colleague Maksim in his talk Waylandifying Chromium has explained how a Wayland is used in Chromium.

Next obvious question would be how to build and run the LaCrOS Browser and contribute to feature LaCrOS development.

Build & Run

Refer to Chromium OS on Linux (linux-chromeos) before building code

You can download a GN args necessary to build a LaCrOS on linux-desktop from an already running linux-lacros-rel build bot.

chromium/src$tools/mb/mb.py gen -m tryserver.chromium.chromiumos -b \'linux-lacros-rel' out/linux-lacros-rel

The above command downloads the GN args and writes the file name args.gn in the output directory out/linux-lacros-rel.

# file: args.gn
also_build_ash_chrome = true
blink_enable_generated_code_formatting = false
chromeos_is_browser_only = true
dcheck_always_on = true
is_component_build = false
is_debug = false
symbol_level = 0
target_os = "chromeos"
use_goma = true

also_build_ash_chrome = true tells a ninja to build Ash-Chrome(wayland server) along with LaCrOS Browser(wayland client)

• Build

  To build the code run the below command from your chromium source directory.

  chromium/src$autoninja -C out/linux-lacros-rel/ chrome all -j500
  

  After build, Ash-Chrome is located at location out/linux-lacros-rel/ash_clang_x64/test_ash_chrome and LaCrOS Browser is located at location out/linux-lacros-rel/chrome.

• Run

  To run the use the below command

  chromium/src$XDG_RUNTIME_DIR=/tmp/ash_chrome_xdg_runtime out/linux-lacros-rel/ash_clang_x64/test_ash_chrome --user-data-dir=/tmp/ash-chrome --enable-wayland-server --no-startup-window --enable-features=LacrosSupport --lacros-chrome-path=$PWD/out/linux-lacros-rel --enable-logging=stderr
  

  It launches the ChromiumOS emulator with support for LaCrOS browser The instructions to run are also publicly available on some issues on crbug.com. If you want more information about the different command line parameters, you can check bugs.

LaCrOS window during BlinkOn 13

In the above image, the window of LaCrOS-Chrome looks visually different from the Ash-Chrome. If you look carefully, you will notice that the scrollbar and the browser window’s frame appear differently and LaCrOS-Chrome does not have drop shadows.

LaCrOS window during BlinkOn 14

This image depicts the state of LaCrOS Browser at the time of the BlinkOn 14 conference. As you can see both browsers look almost identical.

Igalia’s contribution to LaCrOS in 2021

To achieve visual parity between both browsers, our team at Igalia has worked to support various features and bugs related to

• Rounded corners for browser window
• Scrollbars style, thickness and fade behavior
• Resizing behavior
• Shadows (Drop shadow for window & menu, resizer shadow)
• Menus (Right-Click menus, Three-Dot menus)
• Tooltips
• Tablet mode
• Window Snapping
• HiDPI/Mixed DPI
• Touch based window dragging support
• Multiple display
• Scaling
• Enhanced tab dragging

LaCrOS Browser evolution in the last one year can be seen in this video.

This video demonstrated the visual similarities between the Ash-Chrome and LaCrOS-Chrome. You can notice the similarities for

• Drop shadows for a browser window frame
• Resizer shadows after hovering a mouse on browser window edges
• Right-Click menus, Three-Dot menus look and feel is same
• Scrollbars
• Window snapping for LaCrOS Browser window
• Workspace resizing

And more …

In addition to what has been commented above, we recently completed the Multi Desk support and WebUI Tab Strip features:

• Multi-Desk This feature allows the user to add desks to organize multiple windows and multi-task. The LaCrOS-Chrome browser supports this feature by adding a request to a aura_shell wayland protocol. My colleague Minju Kim has contributed to an implementation of this feature. See the working of the Multi-Desk in LaCrOS in the video below.

• WebUi Tab Strip This feature adds a new tab bar to the browser, featuring page thumbnail previews and a touch friendly UI. My colleague Antonio has contributed to an implementation of this feature.

Last but not least, our Chromium team is also working in parallel on fixing several window manager integration issues as part of this work, so please stay tuned for more updates on our efforts related to LaCrOS development :)

set http_proxy="http://<user>:<password>@<ip>:<port>"
set https_proxy="http://<user>:<password>@<ip>:<port>"

• Install build dependencies for WebChimera

Refer link : https://github.com/RSATom/WebChimera.js#windows

1. Visual Studio Community 2013/2015 - (I tried with VS2015)
2. Install VLC Player 32 bit and add it to PATH environment variable (Used to build webchimera)
3. CMake - cmake-3.6.0-rc2-win64-x64.msi
4. Node.js
5. Install NW.js ia32 add it to PATH environment variable (Used to run player)

• Add proxy to npm packaging system

npm config set proxy http://<user>:<password>@<ip>:<port> 
npm config set https-proxy http://<user>:<password>@<ip>:<port>

Check npm configuration in C:\Users<user>.npmrc

https-proxy=http://<user>:<password>@43.88.64.10:8080/
proxy=http://<user>:<password>@43.88.64.10:8080/

• Check cmake generators

cmake --help

• Clone code and build it

git clone https://github.com/RSATom/wcjs-ugly-demo.git
cd wcjs-ugly-demo/
build_nwjs.cmd

• Run

run_nwjs.cmd

export http_proxy="http://<user>:<password>@<ip>:<port>"
export https_proxy="http://<user>:<password>@<ip>:<port>"

• Add proxy to packaging system

If sudo apt-get update is not working, add below line to /etc/apt/apt.conf.

Create /etc/apt/apt.conf if it doesn’t exist and add line below

Acquire::http::Proxy "http://<user>:<password>@43.88.64.10:8080";

sudo gedit /etc/apt/apt.conf

• Install buil dependencies

sudo apt-get update
sudo apt-get install build-essential cmake libvlc-dev
sudo apt-get install vlc
sudo apt-get install git
sudo apt-get install npm 
npm -v
npm config set proxy "http://<userid>:<passwd>@43.88.64.10:8080"
npm config set https-proxy "http://<userid>:<passwd>@43.88.64.10:8080"
sudo npm install -g npm@latest
npm -v

• Clone code and build it

mkdir work
cd work/
git clone https://github.com/RSATom/wcjs-ugly-demo.git
cd wcjs-ugly-demo/
./build_nwjs.sh 

• Run

wget http://dl.nwjs.io/v0.12.0/nwjs-v0.12.0-linux-x64.tar.gz
tar -xvzf nwjs-v0.12.0-linux-x64.tar.gz 
export PATH=/home/abhijeet/work/wcjs-ugly-demo/nwjs-v0.12.0-linux-x64:"$PATH"
gedit index.html (Edit it to add http or https URL for video)
./run_nwjs.sh

• Prerequisite

1. Visual Studio 2015
2. cmake

• Clone binaryen(transcompiler for wasm)

mkdir wasmdemo
cd wasmdemo
git clone https://github.com/WebAssembly/binaryen.git
cd binaryen

• Build code

wasmdemo\binaryen>cmake .
wasmdemo\binaryen>cmake --build . --config Release

• Utilities gets generated after build in binaryen/bin

• Create hello_world.asm.js file with content below

function MyMathModule(global) {
    "use asm";
    var exp = global.Math.exp;
    function doubleExp(value) {
        value = +value;
        return +(+exp(+value) * 2.0);
    }
    return { doubleExp: doubleExp };
}

• wasm-as.exe is a wasm assembler which converts intermediate AST to wasm binary

wasmdemo\binaryen\bin>wasm-as.exe hello_world.wast -o hello_world.wasm

Running WebAssembly in Browser

• We need to access WebAssembly on the Web is through an explicit JS API. Refer https://github.com/WebAssembly/design/blob/master/JS.md for more information.

• Create file index.html with content below :

<script>
fetch("hello_world.wasm")
.then(function(response) {
return response.arrayBuffer();
})
.then(function(buffer) {
var dependencies = {
"global": {},
"env": {}
};
dependencies["global.Math"] = window.Math;
var moduleBufferView = new Uint8Array(buffer);
var myMathModule = Wasm.instantiateModule(moduleBufferView, dependencies);
console.log(myMathModule.exports.doubleExp);
for(var i = 0; i < 5; i++) {
console.log(myMathModule.exports.doubleExp(i));
}
});
</script>

• Run code through local server and open file in Chrome Canary web browser.

Other browsers might give an error as binaryen version used to build wasm file and binaryen version inside browser is different.

TypeError: wasm validation error at offset 8: failed to match binary version

• Output

• References

http://cultureofdevelopment.com/blog/build-your-first-thing-with-web-assembly/ https://github.com/WebAssembly/design/blob/master/JS.md https://github.com/brakmic/brakmic/blob/master/webassembly/COMPILING_WIN32.md

emcc -v

emcc is transcompiler to compile C/C++ code to javascript code.

• Create C/C++ test file

mkdir asmdemo
cd asmdemo
copy NUL hello-world.c (create hello-world.c)

Copy following content into newly created hello-world.c

#include<stdio.h>
int main() {
  printf("hello, world!\n");
  return 0;
}

• Compile C/C++ code using emcc

emcc hello-world.c

it will create file name a.out.js

• Run

node a.out.js

• ASM.js in Browser

• We want HTML so that we can view it in the browser. Enter this command to specify and HTML document.

emcc hello-world.c -o hello.html

• Open hello.html that with your browser, and you can see it as a web page.

• Set following environment variables

    set GYP_DEFINES=host_arch=x64 target_arch=x64 nwjs_sdk=1 disable_nacl=0 proprietary_codecs=1 branding=Chrome

• Go to Ffmpeg source code location :

    <node-webkit-dir>\src\third_party\ffmpeg

• [APPLY PATCH to file ] /chromium/scripts/build_ffmpeg.py

Add support of mxf by enabling it as decoder, demuxer and parser

-      '--enable-decoder=pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw',
-      '--enable-demuxer=ogg,matroska,wav',
-      '--enable-parser=opus,vp3,vorbis,vp8',

+      '--enable-decoder=pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw,mxf',
+      '--enable-demuxer=ogg,matroska,wav,mxf',
+      '--enable-parser=opus,vp3,vorbis,vp8,mxf',

• [APPLY PATCH to file ] : /chromium/scripts/build_ffmpeg.py

Add support of mxf by enabling it as decoder, demuxer and parser

       ['chromeos == 1', {
         'ffmpeg_branding%': '<(branding)OS',
       }, {  # otherwise, assume Chrome/Chromium.
-        'ffmpeg_branding%': '<(branding)',
+         'ffmpeg_branding%': 'Chrome',
       }],
     ],

• Build standalone ffmpeg code for windows 64 bit.

• Build will generate following directory build.x64.win folder.

• Copy config and from build.x64.win:

ffmpeg_src>./chromium/scripts/copy_config.sh

Regenerate ffmpeg gyp files :

ffmpeg_src>python chromium/scripts/generate_gyp.py

Following files get modified after running above commands:

• Force nwjs(chromium) to regenerate ninja files for modified *.h, *.asm, *.gypi (see previous step): Go to nwjs source code location : /node-webkit/src

src>gclientrunhook–force

• Build ffmpeg code using ninja to generate ffmpegsumo.dll:

src>ninja -C out/Debug_x64 ffmpegsumo-j16

• Build nwjs code using ninja and link to ffmpegsumo.dll:

src>ninja -C out/Debug_x64 nw -j16

• Install Msys64 on yourmachine. (msys2-x86_64-20150916.exe)

• Open VS2013 x64 Native Tools Command Prompt C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts

• Run C:/msys64/mingw64_shell.bat in VS2013 x64 Native Tools Command Prompt

• Check current compiler : It should be pointing to VS2013 compiler

• Check current linker, if it is referring to /usr/bin/link then we have to change it by renaming link.exe. Rename C:\msys64\usr\bin\link.exe to C:\msys64\usr\bin \link_old.exe

• YASM : Download YASM from http://www.tortall.net/projects/yasm/releases/yasm-1.3.0-win64.exe
  • Rename yasm-1.3.0-win64.exe to yasm.exe
  • Place yasm.exe somewhere in your PATH environment variable or Add it to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
• Make sure to use mingw64_shell.bat to have the correct MinGW-w64 environment. Run following commands in MinGW-w64 to install dependencies.

    #normal msys2 packages
    pacman -S make pkgconfdiffutils
    # mingw-w64 packages and toolchains
    pacman -S mingw-w64-x86_64-yasm mingw-w64-x86_64-gcc mingw-w64-x86_64-SDL

##Download ffmpeg code##

    mkdir ffmpeg
    cd ffmpeg
    git clone https://github.com/FFmpeg/FFmpeg.git

##Build instructions for ffmpeg## Ffmpeg can be built directly using following commands. If you wish to compile shared libraries, add –enable-shared to your configure options.

    ./configure --toolchain=msvc
    make
    make install

##Build instructions for ffplay##

• Download SDL from http://www.libsdl.org/release/SDL-devel-1.2.15-VC.zip
• Extract it and copy
  • SDL-devel-1.2.15-VC\SDL-1.2.15\include*.* to C:\msys64\mingw64\include\SDL
    • Click -> Copy and Replace
  • SDL-devel-1.2.15-VC\SDL-1.2.15\lib\x64 to C:\msys64\mingw64\lib
• Open file C:\msys64\mingw64\bin\sdl-config and modify following lines

        --libs)
  echo -L${exec_prefix}/lib -lSDLmain -lSDL
        ;;
      --static-libs)
  #    --libs|--static-libs)
  echo -L${exec_prefix}/lib -lSDLmain -lSDL
        ;;

• Run following commands :

./configure --enable-ffplay --toolchain=msvc --disable-shared --enable-static --enable-sdl --extra-ldflags="-Wl,-add-stdcall-alias" --enable-memalign-hack --disable-ffmpeg --pkg-config=sdl-config