esprehn

Clockwise from podium:

Alan Stearns (Adobe)
Cameron McCormack, heycam (Mozilla)
Xidorn Quan (Mozilla)
Jet Villegas (Mozilla)
Rossen (Microsoft)
Bert Bos
Joone Hur
David Baron (Mozilla)

esprehn

var createNewRegistrationContext = (function() {
  // This is slow and means using more memory keeping the iframe window alive,
  // but there's no other way to get a fresh registration context. :(
  var iframe = document.createElement("iframe");
  iframe.style.display = "none";
  document.documentElement.appendChild(iframe);
  var lastDocument = iframe.contentDocument;
  return function() {
    // This keeps nesting template documents to create new registration
    // contexts.

esprehn

/*
  This is a rough approximation of what the algorithm woud do. In an
  implementation you might make the JS Wrapper point to a different
  C++ Element for the duration of the constructor, then make it
  point back at the original C++ element, and move data between them.
  
  This means that the C++ side remains consistent, if you querySelector
  from the document you can still find your element where the constructor
  is running, but if you look at the parentNode/firstChild or attributes
  properties of the element they all appear empty. This means in the

esprehn

/*
  This is a rough approximation of what the algorithm woud do. In an
  implementation you might make the JS Wrapper point to a different
  C++ Element for the duration of the constructor, then make it
  point back at the original C++ element, and move data between them.
  
  This means that the C++ side remains consistent, if you querySelector
  from the document you can still find your element where the constructor
  is running, but if you look at the parentNode/firstChild or attributes
  properties of the element they all appear empty. This means in the

esprehn

// Sample virtual vs switch.
//
// Tested on a MBP:
//
// switch loop(965945 ticks, 0.965945 seconds)
// shuffled switch loop(915787 ticks, 0.915787 seconds)
// switch loop ptrs(993597 ticks, 0.993597 seconds)
// shuffled switch loop ptrs(1957770 ticks, 1.95777 seconds)
// virtual loop(931314 ticks, 0.931314 seconds)
// shuffled virtual loop(1905250 ticks, 1.90525 seconds)

esprehn

// Sample virtual vs switch.
// clang++ -std=c++11 -O3 benchmark3.cpp && ./a.out
//
// Tested on a MBP:
//
// switch loop(10712 ticks, 0.010712 seconds)
// shuffled switch loop(10587 ticks, 0.010587 seconds)
// virtual loop(10583 ticks, 0.010583 seconds)
// shuffled virtual loop(14292 ticks, 0.014292 seconds)

esprehn

// Sample virtual vs switch.
// clang++ -std=c++11 -O3 benchmark2.cpp && ./a.out

#include <iostream>
#include <ctime>
#include <vector>

class Base {
public:
  virtual int test(int value) = 0;

esprehn

// Sample virtual vs switch, compiled with
// clang++ -std=c++11 -O3 benchmark.cpp
//
// Tested on a MBP:
//
// Computed 33332
// virtual loop(474 ticks, 0.000474 seconds)
// Computed 33332
// switch loop(173 ticks, 0.000173 seconds)

esprehn

See the attached test case for an example where Firefox, Chrome/Safari and
old Opera (12) all differ.

1. cd to a directory of files.
2. Run `ruby fouc-server.rb`.

Now the directory will be served on localhost:8000 on your machine,
the directory is also served on localhost:8000/slow and supports a
?delay={seconds} query parameter to cause artificial network delay on that
resource.

esprehn

/*
    Sends and observes notifications by broadcasting notify events.

    Usage:

    <fx-observer for="example" on-notify="{{ handleHashChange }}"></fx-observer>

    FxObserver.notify("example", relatedData);