CrXPRT testers may
remember that back around the time that we began the CrXPRT 2 development process, the Chrome team announced that they were
phasing out support for Portable Native Client (PNaCL) in favor of WebAssembly (WASM). As a first step,
they changed the Chrome OS setting that enabled PNaCL by default. At the time,
this caused problems with the Photo Collage workload in CrXPRT 2015, and even
though we identified a workaround, details in the Chrome team’s announcement led us to conclude
that the workaround might stop working in June 2021. Because of this change, we
decided that the best decision would be to remove the workload from CrXPRT
2, and keep existing CrXPRT 2015 testers informed of any changes with the
In 2020, the Chrome
team also announced that they would be phasing out support for Chrome Apps
altogether starting in June 2021, and would shift their focus to Chrome
extensions. This change would have required us to reassess the viability of
CrXPRT in anything like its current form.
We’re happy to report that
the Chrome team has extended support for PNaCL and existing Chrome Apps through
June 2022. Barring further changes, this means that CrXPRT
2015 (with the workaround) and CrXPRT 2 should continue to serve as reliable
Chrome OS evaluation tools for some time.
If you have any questions about CrXPRT 2, please let us know!
A few months ago, we invited readers to send in their thoughts and ideas about web
technologies and workload scenarios that may be a good fit for the next WebXPRT. We’d like to share a few of those ideas today, and we invite
you to continue to send your feedback. We’re approaching the time when we need to begin firming up
plans for a WebXPRT 4 development cycle in 2021, but there’s still plenty of
time for you to help shape the future of the benchmark.
One of the most
promising ideas for WebXPRT 4 is the potential addition of one or more WebAssembly (WASM) workloads.
WASM is a low-level, binary instruction format that works across all modern browsers.
It offers web developers a great deal of flexibility and provides the speed and
efficiency necessary for running complex client applications in the browser. WASM
enables a variety of workload scenario options, including gaming, video editing, VR, virtual
machines, image recognition, and interactive educational content.
In addition, the
Chrome team is dropping Portable Native Client (PNaCL) support in favor of
WASM, which is why we had to remove a PNaCL workload when updating CrXPRT 2015 to CrXPRT 2. We
generally model CrXPRT workloads on existing WebXPRT workloads, so
familiarizing ourselves with WASM could ultimately benefit more than one XPRT
We are also
considering adding a web-based machine learning workload with TensorFlow for
tasks including image classification, object detection, sentence encoding,
natural language processing, and more. We could also use this technology to
enhance one of WebXPRT’s existing AI-themed workloads, such as Organize Album
using AI or Encrypt Notes and OCR Scan.
Other ideas include using
a WebGL-based workload to target GPUs and investigating ways to incorporate a
battery life test. What do you think? Let us know!
After Chrome OS version 76 moved from Chrome’s Beta channel to the Stable channel last week, we became aware of an issue that occurs when CrXPRT’s Photo Collage workload runs on a Chrome 76 system. We found that the Photo Collage workload produces an error message—“This plugin is not supported on this device”—and the test run does not complete.
The error occurs because the Photo Collage workload uses Portable Native Client (PNaCl), and starting with version 76, the Chrome team changed the way the OS handles PNaCl tasks. Technically, Chrome still supports PNaCl, but the OS now disables the capability by default. Chrome’s current plan is to end support for PNaCl by the end of this year, focusing related development efforts on WebAssembly instead.
We’ll investigate the best path forward during this transition, but for now, testers can use the following workaround that allows CrXPRT to complete successfully. Simply navigate to chrome://flags on the test system, and find the Native Client flag, which is set to “Disabled” by default. Click the toggle switch to “Enabled” to allow native client capabilities, restart the system, and kick off a CrXPRT test in the normal manner.
We’ll update the CrXPRT web page and test documentation to include information about the workaround. In the long term, we’re interested in any suggestions you have for CrXPRT—whether they’re related to PNaCl or not. Please let us know your thoughts!