gi11es

WebGL Artwork Optimization Guide for Android WebView

A step-by-step playbook for eliminating visual jank in WebGL fluid simulations (and similar GPU-heavy artworks) running inside Android WebView. Developed while optimizing Maelstrom by Lake Heckaman on a Qualcomm QCM8550 (Android 13) device.

---

Table of Contents

1. Diagnosis: Identifying the Jank Sources
2. Phase 1: Frame Timing Fixes (Biggest Impact)

gi11es

-- =============================================================================
-- DECOUPLED ACCOUNTING ARCHITECTURE - WORKFLOW EXAMPLES
-- =============================================================================

-- =============================================================================
-- Example 1: Normal User Activation
-- =============================================================================

-- User buys Canvas Jan 1, activates Jan 15
INSERT INTO device_assignments (device_id, user_id, effective_from, assignment_type)

gi11es

2024-12-08 17:18:32.919  7684-7684  cr_WebViewApkApp        com.layer.layer_android_offline      I  Launched version=109.0.5414.123 minSdkVersion=24 isBundle=false processName=com.android.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:0
2024-12-08 17:18:33.010  7634-7710  chromium                com.layer.layer_android_offline      W  [WARNING:display_webview.cc(31)] WebView overlays are enabled!
2024-12-08 17:18:34.077  7634-7634  chromium                com.layer.layer_android_offline      I  [INFO:CONSOLE(14)] "WebGL: INVALID_OPERATION: getUniformLocation: program not linked", source: http://localhost:8080/ces2025/LaurentHoudard-Recompose/index.html (14)
2024-12-08 17:18:34.077  7634-7634  chromium                com.layer.layer_android_offline      I  [INFO:CONSOLE(14)] "WebGL: INVALID_OPERATION: getUniformLocation: program not linked", source: http://localhost:8080/ces2025/LaurentHoudard-Recompose/index.html (14)
2024-12-08 17:18:34.077  7634-7634  chromium                co

gi11es

document.addEventListener('DOMContentLoaded', () => {

  var overlay = new FPSOverlay();
  overlay.visible = true;
});

function clamp(x, min, max) {
  return x < min ? min : x > max ? max : x;
}

gi11es

class Solution:
    def threeSum(self, nums: List[int]) -> List[List[int]]:     
        result = []
        negativeDict = {} # Hash map. keys are the negative values found in the list and values are how many times they occur
        positiveDict = {} # Same for positive values
        zeroCount = 0 # How many zeros are in the list
        
        # Go through the list once to populate the hash maps described above and count zeros - complexity: O(n)
        length = len(nums)
        for i in range(length):

gi11es

Kornel Lesiński, of ImageOptim fame, did an excellent talk at performance.now() about image optimisation. In it, he suggested that a single-frame AV1 video could already outperform a JPG or WebP image in terms of compression ratio. With the single-frame AV1 being half the size of the JPG. I decided to verify that claim.

Compression performance

First, I took a reference image from Wikimedia Commons and generated a "perfect thumbnail" for it, as a PNG. PNG being losslesss, this gives us the reference to aim for. If image compression was lossless, it would end up being 100% identical to that PNG. But by definition, with JPG, WebP and AV1, we're talking about lossy compression. The main question when you use lossy compression is: how much visual quality do you lose?

The images embedded in the article are lossless PNGs generated from the mentione

gi11es

function cpuBenchmark() {
	var blob, worker, work;

	function onMessage() {
		var i,
			startTime,
			amount = 100000000;

		// IE11 doesn't have window.performance exposed inside workers
		if ( !self.performance ) {

gi11es

Guidelines like RAIL are popular in the web performance community. They often define time limits that must be respected, like 100ms for what feels instantaneous, or 1000ms for the limit of acceptable response time.

Prominent people in the performance community keep telling us that there's a lot of science behind those numbers.

I've always been skeptical of that claim, and earlier this year I set out to find out if there's any merit to those numbers by doing an extensive literature review of web performance perception academic research. Here are some of the findings from that project.

Following the citation trail

If you follow paper citations, some classic papers keep showing up as references. And in the world of web performance, two

gi11es

vagrant@mediawiki-vagrant:/tmp/libvmod-xkey$ make
make  all-recursive
make[1]: Entering directory `/tmp/libvmod-xkey'
Making all in src
make[2]: Entering directory `/tmp/libvmod-xkey/src'
/usr/share/varnish/vmodtool.py ../src/vmod_xkey.vcc
make  all-am
make[3]: Entering directory `/tmp/libvmod-xkey/src'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I/usr/include/varnish -Wall -Werror   -g -O2 -MT vcc_if.lo -MD -MP -MF .deps/vcc_if.Tpo -c -o vcc_if.lo vcc_if.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/usr/include/varnish -Wall -Werror -g -O2 -MT vcc_if.lo -MD -MP -MF .deps/vcc_if.Tpo -c vcc_if.c  -fPIC -DPIC -o .libs/vcc_if.o