profile
viewpoint
Ingvar Stepanyan RReverser Google London, UK https://rreverser.com/ Obsessed D2D (tools & specs) programmer, speaker and performance engineer.

emscripten-core/emscripten 19427

Emscripten: An LLVM-to-Web Compiler

acornjs/acorn 6338

A small, fast, JavaScript-based JavaScript parser

fkling/astexplorer 3236

A web tool to explore the ASTs generated by various parsers.

inikulin/parse5 2444

HTML parsing/serialization toolset for Node.js. WHATWG HTML Living Standard (aka HTML5)-compliant.

acornjs/acorn-jsx 462

Alternative, faster React.js JSX parser

binast/binjs-ref 388

Reference implementation for the JavaScript Binary AST format

dherman/esprit 269

A JavaScript parser written in Rust

cloudflare/serde-wasm-bindgen 145

Native integration of Serde with wasm-bindgen

GoogleChromeLabs/wasm-feature-detect 133

A small library to detect which features of WebAssembly are supported.

mourner/delaunator-rs 83

Fast 2D Delaunay triangulation in Rust. A port of Delaunator.

issue commentacornjs/acorn

Removing ALL start/end

Right now I am just removing them from the json, but this is not efficient.

Assuming you're doing hashing on strings, removing from JSON should be trivial via callback param of JSON.stringify.

1fabunicorn

comment created time in 12 hours

pull request commentemscripten-core/emscripten

Document existence of docker image

Thanks!

sbc100

comment created time in 13 hours

pull request commentemscripten-core/emscripten

Document existence of docker image

@kripken Can we merge & push this to the live website? I'd like to announce it with an official link :)

sbc100

comment created time in 14 hours

push eventGoogleChromeLabs/squoosh

Ingvar Stepanyan

commit sha 70bd8158927cf59cc9fe22c427df8d17e6168481

Remove obsolete `free_result` refs

view details

push time in 14 hours

Pull request review commentGoogleChromeLabs/squoosh

AVIF support

+import { EncodeOptions } from '../../src/codecs/avif/encoder-meta';++interface AVIFModule extends EmscriptenWasm.Module {+  encode(data: BufferSource, width: number, height: number, options: EncodeOptions): Uint8Array;+  free_result(): void;

TODO: remove this.

surma

comment created time in 17 hours

issue commentestree/estree

A single specification?

Maintaining a diff between different ES versions is a bit overhead. Can we tag certain commit with es2015, es2016?

Hmm how would we do that cleanly for existing history? Or, even going forward, when some cleanups are applied to previous versions? That seems much trickier to maintain, and at least some of the parsers / consumers care about those versions and the differences between them more than about the "final" result.

I think a more realistic option is to always autogenerate "latest" Markdown like in @j-f1's attempt.

BlueBlazin

comment created time in a day

Pull request review commentWebAssembly/bulk-memory-operations

[test] Fix table index encoding

   "\00asm" "\01\00\00\00"   "\04\04\01"                          ;; Table section with 1 entry   "\70\00\00"                          ;; no max, minimum 0, funcref-  "\09\07\01"                          ;; Element section with 1 entry+  "\09\09\01"                          ;; Element section with 1 entry

@gahaas @binji Ping. Was there any resolution here?

gahaas

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

AVIF support

Thanks for volunteering.

Nice try.

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

AVIF support

+#include <emscripten/bind.h>+#include <emscripten/val.h>+#include "avif/avif.h"++using namespace emscripten;++class RawImage {

@surma Please remove this in favour of ImageData using other codecs as examples.

surma

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

AVIF support

Oh yeah, I’m definitely looking forward to you unleashing the sanitizer on the code base :D

I already did on the existing codecs, now it needs to be done on any new ones by whoever adds them :P

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

AVIF support

 const magicNumberToMimeType = new Map<RegExp, string>([   [/^II*/, 'image/tiff'],   [/^MM\x00*/, 'image/tiff'],   [/^RIFF....WEBPVP8[LX ]/, 'image/webp'],+  [/^\x00\x00\x00\x20\x66\x74\x79\x70\x61\x76\x69\x66\x00\x00\x00\x00/, 'image/avif'],
  [/^\x00\x00\x00 ftypavif\x00\x00\x00\x00/, 'image/avif'],
surma

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

AVIF support

I (hopefully) fixed the leaky bits now :)

The code looks good to me now, but I'd still double-check with sanitizers enabled and the manual "run leak checks" function call like in the blog post to be sure :)

surma

comment created time in a day

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 It is also possible to :ref:`remove specific tools in the SDK using emsdk Using the Docker image ====================== -The entire Emscripten SDK is also available in the form a `docker image+The entire Emscripten SDK is also available in the form of a `docker image <https://hub.docker.com/r/emscripten/emsdk>`_.  For example::    docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \     emscripten/emsdk emcc helloworld.cpp -o helloworld.js -See the docker hub for more details and examples.+See the docker hub page for more details and examples.

If I'm nitpicking...

See the Docker Hub page for more details and examples.
sbc100

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

Update build system for AVIF

Glad to hear!

Overall, I think I'd remove few more intermediate variables, but if you find it cleaner that way, I don't have any strong opinion and this should be good to go :)

I've moved non-build-system related comments to the original PR.

surma

comment created time in a day

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://hub.docker.com/r/emscripten/emsdk>`_.  For example:: -If you want to remove the whole SDK, just delete the directory containing the SDK.+  docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \

Ok, I don't have strict opinion, was just trying to keep examples simple, but your arguments make sense :)

sbc100

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

AVIF support

@surma Just copying some of my unresolved comments from resolved conversation on the build system PR, just so that they're not lost:

I suspect you'll need to free output too, like the official example does, using avifRWDataFree.

You'll probably also want to perform free/destroy above the encodeResult condition, otherwise those structures will get leaked on encoding errors.

surma

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

Update build system for AVIF

The open conversation with ENABLE_EXAMPLES remark still stands. It doesn't cost anything to disable it, and seems relevant to the "build system" PR.

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   avifRGBImage srcRGB;   avifRGBImageSetDefaults(&srcRGB, image);   avifRGBImageAllocatePixels(&srcRGB);--  for (int y = 0; y < height; y++) {-    for (int x = 0; x < width; x++) {-      int pixelOffset = y * width + x;-      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];-      pixel[0] = rgba[pixelOffset * 4 + 0];-      pixel[1] = rgba[pixelOffset * 4 + 1];-      pixel[2] = rgba[pixelOffset * 4 + 2];-      pixel[3] = rgba[pixelOffset * 4 + 3];-    }-  }+  memcpy(srcRGB.pixels, rgba, width * height * 4);

However, if you want to, you can leave this for later, I'm happy to play with it myself if it's not something of interest to you :)

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   avifRGBImage srcRGB;   avifRGBImageSetDefaults(&srcRGB, image);   avifRGBImageAllocatePixels(&srcRGB);--  for (int y = 0; y < height; y++) {-    for (int x = 0; x < width; x++) {-      int pixelOffset = y * width + x;-      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];-      pixel[0] = rgba[pixelOffset * 4 + 0];-      pixel[1] = rgba[pixelOffset * 4 + 1];-      pixel[2] = rgba[pixelOffset * 4 + 2];-      pixel[3] = rgba[pixelOffset * 4 + 3];-    }-  }+  memcpy(srcRGB.pixels, rgba, width * height * 4);

My hunch is that avifRGBImageAllocatePixels does more under the hood.

Looking at the source, the only thing it does is setting rowBytes (which you can set manually).

And option of supplying your own pixels is documented as allowed in README, too: https://github.com/AOMediaCodec/libavif/blob/f41bcea5c6ec1a8b1f28833e878ced4468144a79/README.md#L158

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   avifRGBImage srcRGB;   avifRGBImageSetDefaults(&srcRGB, image);   avifRGBImageAllocatePixels(&srcRGB);--  for (int y = 0; y < height; y++) {-    for (int x = 0; x < width; x++) {-      int pixelOffset = y * width + x;-      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];-      pixel[0] = rgba[pixelOffset * 4 + 0];-      pixel[1] = rgba[pixelOffset * 4 + 1];-      pixel[2] = rgba[pixelOffset * 4 + 2];-      pixel[3] = rgba[pixelOffset * 4 + 3];-    }-  }+  memcpy(srcRGB.pixels, rgba, width * height * 4);

You'll probably also want to perform free/destroy above the encodeResult condition, otherwise those structures will get leaked on encoding errors.

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   avifRGBImage srcRGB;   avifRGBImageSetDefaults(&srcRGB, image);   avifRGBImageAllocatePixels(&srcRGB);--  for (int y = 0; y < height; y++) {-    for (int x = 0; x < width; x++) {-      int pixelOffset = y * width + x;-      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];-      pixel[0] = rgba[pixelOffset * 4 + 0];-      pixel[1] = rgba[pixelOffset * 4 + 1];-      pixel[2] = rgba[pixelOffset * 4 + 2];-      pixel[3] = rgba[pixelOffset * 4 + 3];-    }-  }+  memcpy(srcRGB.pixels, rgba, width * height * 4);

I suspect you'll need to free output too like official example does using avifRWDataFree.

surma

comment created time in a day

pull request commentGoogleChromeLabs/squoosh

Update build system for AVIF

  • Remove package.json

Hmm do we want this? I've kept it in other places, assuming that we want to be able to do npm run build in arbitrary folder instead of fiddling with Docker options in the command-line.

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   avifRGBImage srcRGB;   avifRGBImageSetDefaults(&srcRGB, image);   avifRGBImageAllocatePixels(&srcRGB);--  for (int y = 0; y < height; y++) {-    for (int x = 0; x < width; x++) {-      int pixelOffset = y * width + x;-      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];-      pixel[0] = rgba[pixelOffset * 4 + 0];-      pixel[1] = rgba[pixelOffset * 4 + 1];-      pixel[2] = rgba[pixelOffset * 4 + 2];-      pixel[3] = rgba[pixelOffset * 4 + 3];-    }-  }+  memcpy(srcRGB.pixels, rgba, width * height * 4);

This looks better. What I've meant by my last suggestion is that, as the next step after memcpy, you can just set pixels field to the original pointer - then you don't need to allocate and copy any data at all, and instead AVIF will perform conversion directly from provided source into the YUV format.

One more thing I've noticed is that you call avifRGBImageAllocatePixels but not avifRGBImageFreePixels. As far as I can tell from a quick glance, this will currently cause a memory leak for the allocated pixels.

It can be fixed by calling the *Free* counterpart, but, better yet, if you set pixels field as described above, then you can remove avifRGBImageAllocatePixels line and this issue will go away too, making code both faster and safer :)

I'd probably recommend trying this out in Squoosh with sanitizer enabled once we are done, but this can be left as part of the original PR.

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \+	cd $(LIBAOM_DIR) && \+	curl -L $(LIBAOM_URL)/+archive/$(LIBAOM_VERSION).tar.gz | tar -xzf -++$(CODEC_OUT): $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \

Looks like there is indeed ENABLE_EXAMPLES, in the spirit of other similar options, that you can disable: https://aomedia.googlesource.com/aom/+/refs/heads/master/CMakeLists.txt#227

surma

comment created time in a day

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \+	cd $(LIBAOM_DIR) && \+	curl -L $(LIBAOM_URL)/+archive/$(LIBAOM_VERSION).tar.gz | tar -xzf -++$(CODEC_OUT): $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \

You just mentioned earlier you had to build a bunch of examples, and noticed that they don't seem to be disabled in either of the codecs configs.

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md

Actually, just using folder name should work in this case too (since there are no sources or timestamps involved).

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \

Nitpick: this doesn't have to be part of the &&, it works as a separate command.

Perhaps worth copy-pasting https://github.com/GoogleChromeLabs/squoosh/blob/87955ab9a03401211ef37964cdc60e95a9a96dd9/codecs/webp/Makefile#L50-L52 for consistency between Makefiles? It's also a bit simpler in that output folder is specified directly in tar command.

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \+	cd $(LIBAOM_DIR) && \+	curl -L $(LIBAOM_URL)/+archive/$(LIBAOM_VERSION).tar.gz | tar -xzf -++$(CODEC_OUT): $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \

Does this need similar -DENABLE_DOCS=0 and so on or are they disabled by default here?

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md

Nitpick: instead of README, I'd point to CMakeLists.txt, which is a build config and always guaranteed to be there (otherwise we can't build with existing commands).

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \+	cd $(LIBAOM_DIR) && \+	curl -L $(LIBAOM_URL)/+archive/$(LIBAOM_VERSION).tar.gz | tar -xzf -++$(CODEC_OUT): $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \+		-DAVIF_LOCAL_AOM=1 \+		../ && \+	$(MAKE)++$(CODEC_DIR)/README.md:+	mkdir -p $(CODEC_DIR) && \+	cd $(CODEC_DIR) && \+	curl -L $(CODEC_URL)/archive/$(CODEC_VERSION).tar.gz | tar -xzf - --strip 1 ++clean:+	$(RM) $(OUT_JS) $(OUT_WASM)+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && $(MAKE) clean+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && $(MAKE) clean
	$(MAKE) -C $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) clean
surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = node_modules++CODEC_DIR = $(ROOT_DIR)/libavif+CODEC_BUILD_DIR = build+CODEC_OUT := $(CODEC_DIR)/$(CODEC_BUILD_DIR)/libavif.a ++CODEC_URL = "https://github.com/AOMediaCodec/libavif"+CODEC_VERSION = "v0.8.0"++LIBAOM_DIR := $(CODEC_DIR)/ext/aom+LIBAOM_BUILD_DIR = build.libavif+LIBAOM_OUT := $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR)/libaom.a++LIBAOM_URL = "https://aomedia.googlesource.com/aom/"+LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \ -s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/README.md+	mkdir -p $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	cd $(LIBAOM_DIR)/$(LIBAOM_BUILD_DIR) && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/README.md: $(CODEC_DIR)/README.md+	mkdir -p $(LIBAOM_DIR) && \+	cd $(LIBAOM_DIR) && \+	curl -L $(LIBAOM_URL)/+archive/$(LIBAOM_VERSION).tar.gz | tar -xzf -++$(CODEC_OUT): $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \+		-DAVIF_LOCAL_AOM=1 \+		../ && \+	$(MAKE)++$(CODEC_DIR)/README.md:+	mkdir -p $(CODEC_DIR) && \+	cd $(CODEC_DIR) && \+	curl -L $(CODEC_URL)/archive/$(CODEC_VERSION).tar.gz | tar -xzf - --strip 1 ++clean:+	$(RM) $(OUT_JS) $(OUT_WASM)+	cd $(CODEC_DIR)/$(CODEC_BUILD_DIR) && $(MAKE) clean
	$(MAKE) -C $(CODEC_DIR)/$(CODEC_BUILD_DIR) clean
surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   int depth = 8;   avifPixelFormat format;   switch (options.subsample) {-  case 0:-    format = AVIF_PIXEL_FORMAT_YUV420;-    break;-  case 1:-    format = AVIF_PIXEL_FORMAT_YUV422;-    break;-  case 2:-    format = AVIF_PIXEL_FORMAT_YUV444;-    break;+    case 0:+      format = AVIF_PIXEL_FORMAT_YUV420;+      break;+    case 1:+      format = AVIF_PIXEL_FORMAT_YUV422;+      break;+    case 2:+      format = AVIF_PIXEL_FORMAT_YUV444;+      break;   }-  avifImage *image = avifImageCreate(width, height, depth, format); -  uint8_t *rgba = (uint8_t *)buffer.c_str();+  avifImage* image = avifImageCreate(width, height, depth, format); -  avifImageAllocatePlanes(image, AVIF_PLANES_RGB);-  avifImageAllocatePlanes(image, AVIF_PLANES_A);+  uint8_t* rgba = (uint8_t*)buffer.c_str();++  avifRGBImage srcRGB;+  avifRGBImageSetDefaults(&srcRGB, image);+  avifRGBImageAllocatePixels(&srcRGB);    for (int y = 0; y < height; y++) {     for (int x = 0; x < width; x++) {       int pixelOffset = y * width + x;-      image->rgbPlanes[0][pixelOffset] = rgba[pixelOffset * 4 + 0];-      image->rgbPlanes[1][pixelOffset] = rgba[pixelOffset * 4 + 1];-      image->rgbPlanes[2][pixelOffset] = rgba[pixelOffset * 4 + 2];-      image->alphaPlane[pixelOffset] = rgba[pixelOffset * 4 + 3];+      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];

I just found my similar comment from the original PR, looks like you should be able to assign pixels directly: https://github.com/GoogleChromeLabs/squoosh/pull/722#discussion_r419785905

Here's another relevant comment from AVIF.h: https://github.com/AOMediaCodec/libavif/blob/01ee4caa5ab52b2f6f3e500fd3a0f70e0099b031/include/avif/avif.h#L365-L370

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/

It's not even that much number of variables that bothers me, as complexity of them layered with addprefix combinations to figure out the final value. I think simple concat should be enough for anything except target list :)

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/+LIBAOM_DIR := $(addprefix $(CODEC_DIR)/, $(LIBAOM_RELATIVE))+LIBAOM_OUT_RELATIVE = build.libavif/libaom.a+LIBAOM_OUT := $(addprefix $(LIBAOM_DIR)/, $(LIBAOM_OUT_RELATIVE))++LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \+		-s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/.git/index+	mkdir -p $(LIBAOM_DIR)/build.libavif && \+	cd $(LIBAOM_DIR)/build.libavif && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/.git/index: $(CODEC_DIR)/.git/index+	cd $(CODEC_DIR)/ext && \+	git clone -b $(LIBAOM_VERSION) --depth 1 https://aomedia.googlesource.com/aom aom++$(CODEC_OUT): $(CODEC_DIR)/.git/index $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/build && \+	cd $(CODEC_DIR)/build && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \+		-DAVIF_LOCAL_AOM=1 \+		../ && \+	$(MAKE)++$(CODEC_DIR)/.git/index:+	mkdir -p $(ROOT_DIR) && \+	cd $(ROOT_DIR) && \+	git clone -b $(CODEC_VERSION) --depth 1 https://github.com/AOMediaCodec/libavif $(CODEC_DIR_RELATIVE)++clean:+	$(RM) $(OUT_JS) $(OUT_WASM)+	$(RM) -rf $(LIBAOM_OUT)

Actually, this should probably be replaced with $(MAKE) clean or similar, which knows better what temporary objects to remove and can parallelise such removal with other ones.

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   return val(typed_memory_view(output.size, output.data)); } -void free_result() { avifRWDataFree(&output); }+void free_result() {

Oh, I see there is free_result left. Are you planning to updating the memory management model in a separate PR or should it be done as part of this one?

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

-FROM emscripten/emsdk:1.39.19+FROM emscripten/emsdk:1.40.0

Could you update & rebuild codecs in separate PR perhaps?

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

 val encode(std::string buffer, int width, int height, AvifOptions options) {   int depth = 8;   avifPixelFormat format;   switch (options.subsample) {-  case 0:-    format = AVIF_PIXEL_FORMAT_YUV420;-    break;-  case 1:-    format = AVIF_PIXEL_FORMAT_YUV422;-    break;-  case 2:-    format = AVIF_PIXEL_FORMAT_YUV444;-    break;+    case 0:+      format = AVIF_PIXEL_FORMAT_YUV420;+      break;+    case 1:+      format = AVIF_PIXEL_FORMAT_YUV422;+      break;+    case 2:+      format = AVIF_PIXEL_FORMAT_YUV444;+      break;   }-  avifImage *image = avifImageCreate(width, height, depth, format); -  uint8_t *rgba = (uint8_t *)buffer.c_str();+  avifImage* image = avifImageCreate(width, height, depth, format); -  avifImageAllocatePlanes(image, AVIF_PLANES_RGB);-  avifImageAllocatePlanes(image, AVIF_PLANES_A);+  uint8_t* rgba = (uint8_t*)buffer.c_str();++  avifRGBImage srcRGB;+  avifRGBImageSetDefaults(&srcRGB, image);+  avifRGBImageAllocatePixels(&srcRGB);    for (int y = 0; y < height; y++) {     for (int x = 0; x < width; x++) {       int pixelOffset = y * width + x;-      image->rgbPlanes[0][pixelOffset] = rgba[pixelOffset * 4 + 0];-      image->rgbPlanes[1][pixelOffset] = rgba[pixelOffset * 4 + 1];-      image->rgbPlanes[2][pixelOffset] = rgba[pixelOffset * 4 + 2];-      image->alphaPlane[pixelOffset] = rgba[pixelOffset * 4 + 3];+      uint8_t* pixel = &srcRGB.pixels[(4 * x) + (srcRGB.rowBytes * y)];

Not related to the build system, but it appears that this loop just copies bytes in original order without any reordering or recomputation? If so, can it be replaced entirely with memcpy or similar? Or, maybe, there is a method to create avifRGBImage from existing pointer to avoid copying data altogether?

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/

Let's avoid extra vars and addprefix where they're not necessary.

In this case, I suppose we won't have more than one folder, and addprefix is mainly useful for things like targets (where you might have >1 and want to add the same prefix to each of them). Instead, in this case it could be just

LIBAOM_DIR := $(CODEC_DIR)/ext/aom

Same for some other cases around.

surma

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8+  } else if (options.ecmaVersion == null) {+    if (!warnedAboutEcmaVersion && typeof console === "object" && console.warn) {+      warnedAboutEcmaVersion = true+      console.warn("Since Acorn 8.0.0, options.ecmaVersion is required.\nDefaulting to 2020, but this will stop working in the future.")+    }+    options.ecmaVersion = 11+  } else if (options.ecmaVersion >= 2015) {

It costs nothing, but it creates a weird split IMO. I'm a big fan of consistency :D

marijnh

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8+  } else if (options.ecmaVersion == null) {

You don't really need it, because null would behave correctly there too, but yeah, it doesn't matter much.

marijnh

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8+  } else if (options.ecmaVersion == null) {+    if (!warnedAboutEcmaVersion && typeof console === "object" && console.warn) {+      warnedAboutEcmaVersion = true+      console.warn("Since Acorn 8.0.0, options.ecmaVersion is required.\nDefaulting to 2020, but this will stop working in the future.")+    }+    options.ecmaVersion = 11+  } else if (options.ecmaVersion >= 2015) {

I wonder if, as part of this version overhaul, we should deprecate non-year based versions beyond ES6 (ES7?). I don't think anyone uses ES8+ in the wild, and it might be good to enforce a single standard that community prefers.

marijnh

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8+  } else if (options.ecmaVersion == null) {

I see. I guess in my mind it's "obviously" the same as zero by now, but I can see that argument as it's context-dependant :)

marijnh

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8+  } else if (options.ecmaVersion == null) {

If this is expected to be the rare "error case", let's move it to the end as less likely branch?

marijnh

comment created time in 2 days

Pull request review commentacornjs/acorn

Major release 8.0.0

 export const defaultOptions = {  // Interpret and default an options object +let warnedAboutEcmaVersion = false+ export function getOptions(opts) {   let options = {}    for (let opt in defaultOptions)     options[opt] = opts && has(opts, opt) ? opts[opt] : defaultOptions[opt] -  if (options.ecmaVersion >= 2015)+  if (options.ecmaVersion === "latest") {+    options.ecmaVersion = 1e8

I'd probably even go for something simpler and more obvious as 3000, but sgtm either way.

marijnh

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/+LIBAOM_DIR := $(addprefix $(CODEC_DIR)/, $(LIBAOM_RELATIVE))+LIBAOM_OUT_RELATIVE = build.libavif/libaom.a+LIBAOM_OUT := $(addprefix $(LIBAOM_DIR)/, $(LIBAOM_OUT_RELATIVE))++LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \+		-s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/.git/index+	mkdir -p $(LIBAOM_DIR)/build.libavif && \+	cd $(LIBAOM_DIR)/build.libavif && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/.git/index: $(CODEC_DIR)/.git/index+	cd $(CODEC_DIR)/ext && \+	git clone -b $(LIBAOM_VERSION) --depth 1 https://aomedia.googlesource.com/aom aom

Same here about Git repo vs tar archive as below.

surma

comment created time in 2 days

pull request commentGoogleChromeLabs/squoosh

Fix install button position

Ping.

RReverser

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/+LIBAOM_DIR := $(addprefix $(CODEC_DIR)/, $(LIBAOM_RELATIVE))+LIBAOM_OUT_RELATIVE = build.libavif/libaom.a+LIBAOM_OUT := $(addprefix $(LIBAOM_DIR)/, $(LIBAOM_OUT_RELATIVE))++LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \+		-s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/.git/index+	mkdir -p $(LIBAOM_DIR)/build.libavif && \+	cd $(LIBAOM_DIR)/build.libavif && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/.git/index: $(CODEC_DIR)/.git/index+	cd $(CODEC_DIR)/ext && \+	git clone -b $(LIBAOM_VERSION) --depth 1 https://aomedia.googlesource.com/aom aom++$(CODEC_OUT): $(CODEC_DIR)/.git/index $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/build && \+	cd $(CODEC_DIR)/build && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \+		-DAVIF_LOCAL_AOM=1 \+		../ && \+	$(MAKE)++$(CODEC_DIR)/.git/index:+	mkdir -p $(ROOT_DIR) && \+	cd $(ROOT_DIR) && \+	git clone -b $(CODEC_VERSION) --depth 1 https://github.com/AOMediaCodec/libavif $(CODEC_DIR_RELATIVE)

Do we need the repo as an actual Git repo? If not, let's follow precedent from other codecs and just use CODEC_URL set to an archive from Github releases + curl + tar instead.

It should be both simpler to download and faster than git clone (which has to do extra work to download Git-specific objects for history and stuff).

surma

comment created time in 2 days

Pull request review commentGoogleChromeLabs/squoosh

Update build system for AVIF

+ROOT_DIR = ./node_modules+CODEC_DIR_RELATIVE = libavif+CODEC_DIR = $(addprefix $(ROOT_DIR)/, $(CODEC_DIR_RELATIVE))+CODEC_OUT_RELATIVE = build/libavif.a+CODEC_OUT := $(addprefix $(CODEC_DIR)/, $(CODEC_OUT_RELATIVE))++CODEC_VERSION = "v0.8.0"++LIBAOM_RELATIVE = ext/aom/+LIBAOM_DIR := $(addprefix $(CODEC_DIR)/, $(LIBAOM_RELATIVE))+LIBAOM_OUT_RELATIVE = build.libavif/libaom.a+LIBAOM_OUT := $(addprefix $(LIBAOM_DIR)/, $(LIBAOM_OUT_RELATIVE))++LIBAOM_VERSION = "v2.0.0"++OUT_JS = enc/avif_enc.js dec/avif_dec.js+OUT_WASM = $(OUT_JS:.js=.wasm)++.PHONY: all clean++all: $(OUT_JS)++%.js: %.cpp $(LIBAOM_OUT) $(CODEC_OUT)+	$(CXX) \+		-I $(CODEC_DIR)/include \+		${CXXFLAGS} \+		${LDFLAGS} \+		--bind \+		--closure 1 \+		-s ALLOW_MEMORY_GROWTH=1 \+		-s MODULARIZE=1 \+		-s 'EXPORT_NAME="$(basename $(@F))"' \+		-o $@ \+		$+++$(LIBAOM_OUT): $(LIBAOM_DIR)/.git/index+	mkdir -p $(LIBAOM_DIR)/build.libavif && \+	cd $(LIBAOM_DIR)/build.libavif && \+	emcmake cmake \+		-DCMAKE_BUILD_TYPE=Release \+		-DENABLE_CCACHE=0 \+		-DAOM_TARGET_CPU=generic \+		-DENABLE_DOCS=0 \+		-DENABLE_TESTS=0 \+		-DCONFIG_ACCOUNTING=1 \+		-DCONFIG_INSPECTION=0 \+		-DCONFIG_MULTITHREAD=0 \+		-DCONFIG_RUNTIME_CPU_DETECT=0 \+		-DCONFIG_WEBM_IO=0 \+		../ && \+	$(MAKE) ++$(LIBAOM_DIR)/.git/index: $(CODEC_DIR)/.git/index+	cd $(CODEC_DIR)/ext && \+	git clone -b $(LIBAOM_VERSION) --depth 1 https://aomedia.googlesource.com/aom aom++$(CODEC_OUT): $(CODEC_DIR)/.git/index $(LIBAOM_OUT)+	mkdir -p $(CODEC_DIR)/build && \+	cd $(CODEC_DIR)/build && \+	emcmake cmake \+		DCMAKE_BUILD_TYPE=Release \+		-DAVIF_CODEC_AOM=1 \+		-DAVIF_LOCAL_AOM=1 \+		../ && \+	$(MAKE)++$(CODEC_DIR)/.git/index:+	mkdir -p $(ROOT_DIR) && \+	cd $(ROOT_DIR) && \+	git clone -b $(CODEC_VERSION) --depth 1 https://github.com/AOMediaCodec/libavif $(CODEC_DIR_RELATIVE)++clean:+	$(RM) $(OUT_JS) $(OUT_WASM)+	$(RM) -rf $(LIBAOM_OUT)

You don't need -f, it's part of $(RM).

surma

comment created time in 2 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://hub.docker.com/r/emscripten/emsdk>`_.  For example:: -If you want to remove the whole SDK, just delete the directory containing the SDK.+  docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \+    emscripten/emsdk emcc helloworld.cpp -o helloworld.js

Great, thanks for confirming.

sbc100

comment created time in 3 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://hub.docker.com/r/emscripten/emsdk>`_.  For example:: -If you want to remove the whole SDK, just delete the directory containing the SDK.+  docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \

running the command with -u

Did you mean "without" here? Interesting, haven't noticed any issues so far - we don't use -u in Squoosh and I was able to remove files without sudo every time.

sbc100

comment created time in 3 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

However, there is still a regression between 1.40 and 1.41, probably due to std increases?

Btw, I think that another reason is that wasm-snip can only remove dead code, but not dead data, because by the time Wasm is produced, the data sections are flattened. This is a known issue for many post-optimisation tooling, and the only way to fix this would be on compiler side before Wasm is linked together.

RReverser

comment created time in 3 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://hub.docker.com/r/emscripten/emsdk>`_.  For example:: -If you want to remove the whole SDK, just delete the directory containing the SDK.+  docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \+    emscripten/emsdk emcc helloworld.cpp -o helloworld.js

Just in case - does this command actually work? We mount into /src, I don't remember if it's the default dir, or we need to cd first.

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://hub.docker.com/r/emscripten/emsdk>`_.  For example:: -If you want to remove the whole SDK, just delete the directory containing the SDK.+  docker run --rm -v $(pwd):/src -u $(id -u):$(id -g) \
  docker run --rm -v $(pwd):/src \

just to keep the example simpler, I wouldn't bother with permissions here. It should work with defaults too.

sbc100

comment created time in 4 days

issue commentemscripten-core/emscripten

Document existence and usage of "official" emsdk docker images.

At the moment I've added info to the header about deprecation: hub.docker.com/repository/docker/trzeci/emscripten

I think this notice looks pretty good and self-explanatory. Although I'm not sure about "IS TO BE DEPRECATED" wording - is it technically not deprecated yet?

sbc100

comment created time in 4 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

Oh, also note that you're using -O3 not -Os - probably the reason why output files in 1.40 in your experiment are larger than mine, even after wasm-snip.

RReverser

comment created time in 4 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

disabling console_error_panic_hook

I didn't even notice that that codec has it enabled by default, we should disable it 🤦‍♂️ But yeah, as you said, ~same regression remains regardless.

Btw, why is there n/a pkg/squooshhqx_bg.wasm in 1.40? Could these files not be produced or some other reason?

RReverser

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 The package manager can do many other maintenance tasks ranging from fetching sp .. _downloads-uninstall-the-sdk:  Uninstalling the Emscripten SDK-========================================================+===============================++If you want to remove the whole SDK, just delete the directory containing the+SDK.++It is also possible to :ref:`remove specific tools in the SDK using emsdk+<emsdk-remove-tool-sdk>`.++Using the Docker image+======================++The entire Emscripten SDK is also available in the form a `docker image+<https://ci.chromium.org/p/emscripten-releases>`_.  For example::

Is this the right link? It should probably be linking to the Docker Hub page.

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 Installation instructions  First check the :ref:`Platform-specific notes <platform-notes-installation_instructions-SDK>` below and install any prerequisites. -The core Emscripten SDK (emsdk) driver is a Python script. You can get it for the first time with+The core Emscripten SDK (emsdk) driver is a Python script. You can get it for

Ah it's a source-level line split. I see.

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 Installation instructions  First check the :ref:`Platform-specific notes <platform-notes-installation_instructions-SDK>` below and install any prerequisites. -The core Emscripten SDK (emsdk) driver is a Python script. You can get it for the first time with+The core Emscripten SDK (emsdk) driver is a Python script. You can get it for

Github highlights a change here, but I don't see what has changed...

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Document existence of docker image

 Download and install .. note:: You can also :ref:`build Emscripten from source <installing-from-source>` if you prefer that to downloading binaries using the emsdk.  .. note:: There are additional ways to install Emscripten than the instructions-    below, for example, using brew on MacOS, the package manager on your linux-    distro, or a Docker image, etc. However, the emsdk is the only officially-    supported way to use Emscripten that is supported by the Emscripten-    project, and the only one that we constantly test+    below, for example, using homebrew on MacOS, the package manager on your linux
    below, for example, using Homebrew on MacOS, the package manager on your Linux

if we use a tool name and not command name, probably need to use official capitalisation.

sbc100

comment created time in 4 days

pull request commentGoogleChromeLabs/squoosh

Fix install button position

Did the "merge branch" thingy, now with Squash & Merge the extra commit shouldn't matter :)

RReverser

comment created time in 4 days

push eventGoogleChromeLabs/squoosh

Pete LePage

commit sha aac30e6fd3a2e09957061cc65803b8dc7c097bdf

Don't fire install analytics on hidden pages

view details

Pete LePage

commit sha b8d921ec1670aa08828345d64207373b0fbce225

Merge branch 'dev' into analytics-update-3

view details

Jake Archibald

commit sha ddbeaa0870a52d38d7d7f11fdfbbc8264912f6b8

Merge branch 'dev' into analytics-update-3

view details

Ingvar Stepanyan

commit sha 1a26057452814d8d9ba1a92693f3528eaf98a134

Switch from napa to curl Instead of using 127 deps brought by napa just to download the one dependency we actually care about, just use curl & tar directly from Makefile.

view details

Jake Archibald

commit sha ed451e4dfa07a9e2ad99dd9880aa567c415f09f2

"native" to "builtin" (#788)

view details

Pete LePage

commit sha ecb0b15cdcd21576098cd77189e5d31f1f44e0c6

Merge branch 'dev' into analytics-update-3

view details

Pete LePage

commit sha 87955ab9a03401211ef37964cdc60e95a9a96dd9

Merge pull request #784 from petele/analytics-update-3 Don't fire install analytics on hidden pages

view details

Ingvar Stepanyan

commit sha c43f75f1f2691b4dfa57849cabc3cd0abe4bc9d6

Merge branch 'dev' into button-position

view details

push time in 4 days

pull request commentGoogleChromeLabs/squoosh

Fix install button position

Ah, it's just an unrebased branch.

RReverser

comment created time in 4 days

PR opened GoogleChromeLabs/squoosh

Fix install button position

Add position: relative to the parent div that owns the scrollbar, so that Install button positions itself relative to it and not to the whole document.

Fixes a bug where button would get rendered on top of a scrollbar.

+27 -3455

0 comment

10 changed files

pr created time in 4 days

create barnchGoogleChromeLabs/squoosh

branch : button-position

created branch time in 4 days

issue commentemscripten-core/emscripten

Document existence and usage of "official" emsdk docker images.

Cross-posting suggestion from chat: I think the best place to document these would be on https://emscripten.org/docs/getting_started/downloads.html by adding a new "Usage from Docker" section and updating the Note which currently mentions Docker images only as an unofficial / unsupported 3rd-party thing.

sbc100

comment created time in 5 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

But maybe we could ship a track-caller-less binary for, say, wasm?

I'd imagine it would be useful for any targets that use opt-level = "s" / "z", but if that's infeasible, Wasm could be a good start I guess.

More generally, could there be a way to tie this feature to the debuginfo knob? It seems reasonable to assume that users who disable line/column location info in debug sections, don't care much about line/column info in other places either.

RReverser

comment created time in 5 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

Ah interesting. Is there anything that could be done about it / any way to disable for size-optimized builds (hopefully, without going the unstable -Z build-std route)? Seems like a fairly significant size regression for targets that care about it.

RReverser

comment created time in 5 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

Just realised I forgot to cc @CryZe (author of HQX crate we're wrapping) who might be also interested in this investigation.

RReverser

comment created time in 5 days

issue commentrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

@alexcrichton Right, sorry. As I mentioned, it's HQX codec. Basically you need to go to this folder: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/hqx and inside run npm run build, which will build a base Docker image and the codec itself.

Alternatively, if you don't want to use Docker here, you can use wasm-pack build or cargo build --target=... directly in the same folder too, just make sure to set the right Rust versions.

In terms of tooling, in this case npm invokes Docker, which downloads Rust image and invokes wasm-pack, which calls cargo build + wasm-opt. You should get the same results no matter which level of abstraction you're on - as I said above, you can use pure cargo build just as well.

I've shown sizes after wasm-opt in the spreadsheet / graph, because, I think, they're interesting from real-world perspective, but, as you can also see from the graph, the actual data section size difference between 1.40 and 1.41 comes from a "raw" target/wasm32-unknown-unknown/release/... Wasm file, and can be investigated independently from all the other tooling.

RReverser

comment created time in 5 days

issue commentWebAssembly/binaryen

wasm-opt crashes

Unfortunately, wasm-pack is just stuck on a bit old version of wasm-opt. They haven't had a release for some time, but if they do, that should fix it.

droundy

comment created time in 6 days

issue openedrust-lang/rust

WebAssembly size regression between 1.40 and 1.41

While upgrading the build configs and compiler versions in squoosh.app in c5c520a (#777), we've noticed a significant size increase in one of the image codecs - HQX.

Normally we ignore fluctuations between versions, as they are expected, but in this particular case the resulting file grew from 219KB to 381KB - by 162KB or 74%.

For now we reverted that codec to the Rust version it was initially built with - 1.39

Meanwhile, I've started investigating and going through Rust versions starting from 1.39 to the latest 1.45 to find the one that introduced the regression. This process is a bit slow, but in the end I've ended up with the following pinpoint changes, file sizes & included wasm-objdump -h logs:

<details> <code> 1.40: (before wasm-opt) -a--- 30-Jul-20 15:07 682058 squooshhqx.wasm Type start=0x0000000a end=0x00000075 (size=0x0000006b) count: 16 Import start=0x00000078 end=0x0000012a (size=0x000000b2) count: 3 Function start=0x0000012c end=0x00000191 (size=0x00000065) count: 100 Table start=0x00000193 end=0x00000198 (size=0x00000005) count: 1 Memory start=0x0000019a end=0x0000019d (size=0x00000003) count: 1 Global start=0x0000019f end=0x000001b8 (size=0x00000019) count: 3 Export start=0x000001bb end=0x0000035c (size=0x000001a1) count: 16 Elem start=0x0000035e end=0x0000037e (size=0x00000020) count: 1 Code start=0x00000382 end=0x0005569e (size=0x0005531c) count: 100 Data start=0x000556a1 end=0x000586b8 (size=0x00003017) count: 3 Custom start=0x000586bc end=0x0006cbea (size=0x0001452e) ".debug_info" Custom start=0x0006cbec end=0x0006cbfd (size=0x00000011) ".debug_macinfo" Custom start=0x0006cc01 end=0x00073e43 (size=0x00007242) ".debug_pubtypes" Custom start=0x00073e47 end=0x0007874d (size=0x00004906) ".debug_ranges" Custom start=0x00078750 end=0x00078f98 (size=0x00000848) ".debug_abbrev" Custom start=0x00078f9b end=0x0007918f (size=0x000001f4) "__wasm_bindgen_unstable" Custom start=0x00079193 end=0x00088b44 (size=0x0000f9b1) ".debug_line" Custom start=0x00088b48 end=0x000a09d6 (size=0x00017e8e) ".debug_str" Custom start=0x000a09da end=0x000a4fb4 (size=0x000045da) ".debug_pubnames" Custom start=0x000a4fb7 end=0x000a67fb (size=0x00001844) "name" Custom start=0x000a67fd end=0x000a684a (size=0x0000004d) "producers" (after wasm-opt) -a--- 30-Jul-20 15:15 220121 squooshhqx_bg.wasm Type start=0x0000000a end=0x00000075 (size=0x0000006b) count: 16 Function start=0x00000077 end=0x000000c2 (size=0x0000004b) count: 74 Table start=0x000000c4 end=0x000000c9 (size=0x00000005) count: 1 Memory start=0x000000cb end=0x000000ce (size=0x00000003) count: 1 Global start=0x000000d0 end=0x000000d9 (size=0x00000009) count: 1 Export start=0x000000db end=0x00000114 (size=0x00000039) count: 4 Elem start=0x00000116 end=0x00000136 (size=0x00000020) count: 1 Code start=0x0000013a end=0x00033193 (size=0x00033059) count: 74 Data start=0x00033196 end=0x00035b5c (size=0x000029c6) count: 44 Custom start=0x00035b5e end=0x00035bd9 (size=0x0000007b) "producers"

1.41+ (before wasm-opt) -a--- 30-Jul-20 15:23 777633 squooshhqx.wasm Type start=0x0000000a end=0x00000075 (size=0x0000006b) count: 16 Import start=0x00000078 end=0x0000012a (size=0x000000b2) count: 3 Function start=0x0000012c end=0x00000190 (size=0x00000064) count: 99 Table start=0x00000192 end=0x00000197 (size=0x00000005) count: 1 Memory start=0x00000199 end=0x0000019c (size=0x00000003) count: 1 Global start=0x0000019e end=0x000001b7 (size=0x00000019) count: 3 Export start=0x000001ba end=0x0000035b (size=0x000001a1) count: 16 Elem start=0x0000035d end=0x0000037d (size=0x00000020) count: 1 Code start=0x00000381 end=0x00055365 (size=0x00054fe4) count: 99 Data start=0x00055369 end=0x0006e245 (size=0x00018edc) count: 3 Custom start=0x0006e249 end=0x0008284e (size=0x00014605) ".debug_info" Custom start=0x00082850 end=0x00082861 (size=0x00000011) ".debug_macinfo" Custom start=0x00082865 end=0x00089b4f (size=0x000072ea) ".debug_pubtypes" Custom start=0x00089b53 end=0x0008e531 (size=0x000049de) ".debug_ranges" Custom start=0x0008e534 end=0x0008ef13 (size=0x000009df) ".debug_aranges" Custom start=0x0008ef16 end=0x0008f69d (size=0x00000787) ".debug_abbrev" Custom start=0x0008f6a0 end=0x0008f894 (size=0x000001f4) "__wasm_bindgen_unstable" Custom start=0x0008f898 end=0x0009f3f5 (size=0x0000fb5d) ".debug_line" Custom start=0x0009f3f9 end=0x000b7b31 (size=0x00018738) ".debug_str" Custom start=0x000b7b35 end=0x000bc543 (size=0x00004a0e) ".debug_pubnames" Custom start=0x000bc546 end=0x000bdd52 (size=0x0000180c) "name" Custom start=0x000bdd54 end=0x000bdda1 (size=0x0000004d) "producers" (after wasm-opt) -a--- 30-Jul-20 15:24 391443 squooshhqx_bg.wasm Type start=0x0000000a end=0x00000075 (size=0x0000006b) count: 16 Function start=0x00000077 end=0x000000c2 (size=0x0000004b) count: 74 Table start=0x000000c4 end=0x000000c9 (size=0x00000005) count: 1 Memory start=0x000000cb end=0x000000ce (size=0x00000003) count: 1 Global start=0x000000d0 end=0x000000d9 (size=0x00000009) count: 1 Export start=0x000000db end=0x00000114 (size=0x00000039) count: 4 Elem start=0x00000116 end=0x00000136 (size=0x00000020) count: 1 Code start=0x0000013a end=0x00047009 (size=0x00046ecf) count: 74 Data start=0x0004700d end=0x0005f896 (size=0x00018889) count: 44 Custom start=0x0005f898 end=0x0005f913 (size=0x0000007b) "producers"

1.44+: (before wasm-opt) -a--- 30-Jul-20 15:49 547075 squooshhqx.wasm Type start=0x0000000a end=0x0000007d (size=0x00000073) count: 17 Import start=0x00000080 end=0x00000132 (size=0x000000b2) count: 3 Function start=0x00000134 end=0x00000198 (size=0x00000064) count: 99 Table start=0x0000019a end=0x0000019f (size=0x00000005) count: 1 Memory start=0x000001a1 end=0x000001a4 (size=0x00000003) count: 1 Global start=0x000001a6 end=0x000001bf (size=0x00000019) count: 3 Export start=0x000001c2 end=0x00000363 (size=0x000001a1) count: 16 Elem start=0x00000365 end=0x00000385 (size=0x00000020) count: 1 Code start=0x00000389 end=0x00055466 (size=0x000550dd) count: 99 Data start=0x0005546a end=0x0006da2a (size=0x000185c0) count: 3 Custom start=0x0006da2e end=0x00072084 (size=0x00004656) ".debug_info" Custom start=0x00072086 end=0x00072098 (size=0x00000012) ".debug_macinfo" Custom start=0x0007209a end=0x00072116 (size=0x0000007c) ".debug_pubtypes" Custom start=0x00072119 end=0x000741df (size=0x000020c6) ".debug_ranges" Custom start=0x000741e2 end=0x00074469 (size=0x00000287) ".debug_aranges" Custom start=0x0007446c end=0x0007483b (size=0x000003cf) ".debug_abbrev" Custom start=0x0007483e end=0x00074a32 (size=0x000001f4) "__wasm_bindgen_unstable" Custom start=0x00074a35 end=0x00077f18 (size=0x000034e3) ".debug_line" Custom start=0x00077f1c end=0x000810cf (size=0x000091b3) ".debug_str" Custom start=0x000810d2 end=0x00083fd7 (size=0x00002f05) ".debug_pubnames" Custom start=0x00083fda end=0x000858b4 (size=0x000018da) "name" Custom start=0x000858b6 end=0x00085903 (size=0x0000004d) "producers" (after wasm-opt) -a--- 30-Jul-20 15:50 389871 squooshhqx_bg.wasm Type start=0x0000000a end=0x0000007d (size=0x00000073) count: 17 Function start=0x0000007f end=0x000000cb (size=0x0000004c) count: 75 Table start=0x000000cd end=0x000000d2 (size=0x00000005) count: 1 Memory start=0x000000d4 end=0x000000d7 (size=0x00000003) count: 1 Global start=0x000000d9 end=0x000000e2 (size=0x00000009) count: 1 Export start=0x000000e4 end=0x0000011d (size=0x00000039) count: 4 Elem start=0x0000011f end=0x0000013f (size=0x00000020) count: 1 Code start=0x00000143 end=0x00047111 (size=0x00046fce) count: 75 Data start=0x00047115 end=0x0005f272 (size=0x0001815d) count: 2 Custom start=0x0005f274 end=0x0005f2ef (size=0x0000007b) "producers" </code> </details>

The TL;DR of our build config is opt-level = "s" and lto = true, and then using wasm-pack to also optimise for size & strip debug info.

The logs above can be a bit verbose, and raw file sizes reflect changes also in size of debug sections and such, which are not very interesting in this context. Where I use 1.41+ or 1.44+, it means that following versions exhibit pretty much same sizes par the normal fluctuation, and only versions with significant increase are kept.

To make changes a bit easier to analyse, I've split out only code and data section sizes in the following spreadsheet: https://docs.google.com/spreadsheets/d/1ToE7Th7fp_VuQwws45ZgwBV1Pg09U061na0yFDaLwpk/edit?usp=sharing

Here is the graph showing the code and data increase between those version groups:

Chart

As you can see from raw logs, 1.44+ produces smaller raw file but it has comparable code and data sections sizes, and remains at the 1.41+ level after wasm-opt, which suggests the decrease is mainly around debug info, and not very interesting to us.

However, the change between 1.40 and 1.41 is more radical: the data section has increased from 12KB to 100KB (by 88KB or 8.3x of the original), and, while the code section almost hasn't changed, it can't be optimised by wasm-opt as well anymore.

I don't have enough insight and didn't dig deeper into Wasm, but suspect this is not a separate issue, but related to the data section increase - probably some data sections kept by Rust / LLVM, consequently, don't allow wasm-opt to DCE out some unused code that could be removed before.

Would appreciate if someone on the Rust side could take over further investigation and happy to help out with build instructions to reproduce. Although we use Dockerfiles, so it should be fairly straightforward to build.

Thanks!

created time in 6 days

PR merged v8/v8.dev

List numbers overflow on mobile devices #378 cla: yes
+1 -1
1 commit in v8/v8.dev/tree/main

0 comment

1 changed file

vnoitkumar

pr closed time in 6 days

pull request commentv8/v8.dev

Fixed overflow on narrow viewports issue #378

Merged #396 instead. Thanks!

yozaam

comment created time in 6 days

issue closedv8/v8.dev

List numbers overflow on mobile devices

Looks like once we hit 100 posts, we started overflowing list item numbers for blog posts on mobile viewports, so they end up getting truncated.

Screenshot from DevTools emulation of Pixel 2:

iPhone 5 / SE:

iPhone X:

Also confirmed manually on my Android phone.

closed time in 6 days

RReverser

push eventv8/v8.dev

Vinoth Kumar

commit sha 68fd701c308d0157276c8918e9039c5df8669bd9

List numbers overflow on mobile devices #378 (#396)

view details

push time in 6 days

PR closed v8/v8.dev

Fixed overflow on narrow viewports issue #378 cla: yes

List numbers overflow on mobile devices #378

Hey, this is how it will look, fixing the overflow issue: Screenshot 2020-06-28 at 11 18 32 PM

But if I make it 14px it will look like this:

Screenshot 2020-06-28 at 11 26 56 PM

Should I make it 13/14px for a better style?

+1 -1

1 comment

1 changed file

yozaam

pr closed time in 6 days

issue commentv8/v8.dev

List numbers overflow on mobile devices

Thanks @tomayac, I shall do that then.

RReverser

comment created time in 6 days

delete branch GoogleChromeLabs/squoosh

delete branch : curl-codecs

delete time in 6 days

PR merged GoogleChromeLabs/squoosh

Switch from napa to curl

Instead of using 127 deps brought by napa just to download the one dependency we actually care about, just use curl & tar directly from Makefile.

+26 -3455

5 comments

9 changed files

RReverser

pr closed time in 6 days

push eventGoogleChromeLabs/squoosh

Ingvar Stepanyan

commit sha 1a26057452814d8d9ba1a92693f3528eaf98a134

Switch from napa to curl Instead of using 127 deps brought by napa just to download the one dependency we actually care about, just use curl & tar directly from Makefile.

view details

push time in 6 days

pull request commentGoogleChromeLabs/squoosh

Switch from napa to curl

Ah yeah it did, but is it useful for user without ability to build?

RReverser

comment created time in 6 days

pull request commentGoogleChromeLabs/squoosh

Switch from napa to curl

We already build inside Docker, and codecs already use Make, so no :)

RReverser

comment created time in 6 days

PR opened GoogleChromeLabs/squoosh

Switch from napa to curl

Instead of using 127 deps brought by napa just to download the one dependency we actually care about, just use curl & tar directly from Makefile.

+26 -3455

0 comment

9 changed files

pr created time in 6 days

create barnchGoogleChromeLabs/squoosh

branch : curl-codecs

created branch time in 6 days

issue commentWebAssembly/WASI

Clarify fd_seek behaviour for out-of-bounds access

It all comes down to finding volunteers to step up and do the work.

Heh, to be fair I was rather hoping that, instead of external volunteers, participating implementors / companies would be able to dedicate time to this as part of the spec work :)

RReverser

comment created time in 6 days

issue commentrustwasm/wasm-pack

Support for wasm32-wasi target?

For WASI it is necessary to pass in the WASI functions, but wasm-bindgen doesn't do this, therefore wasm32-wasi won't work.

Ah yeah, that's a good point, these imports would have to be propagated via JS wrapper.

iceiix

comment created time in 6 days

issue commentrustwasm/wasm-pack

Support for wasm32-wasi target?

@Pauan

I think this needs to be added to wasm-bindgen first before it can be added to wasm-pack.

Does wasm-bindgen differentiate or, indeed, even know, which target Wasm was built with? I think it should already work with wasm32-wasi built Wasm files like with the unknown ones.

IIUC the issue is only in wasm-pack because it passes the --target to cargo build, and that target is currently hardcoded to wasm32-unknown-unknown.

iceiix

comment created time in 7 days

issue openedv8/v8.dev

Auto-add table-wrapper via custom Markdown rendering

I've seen @mathiasbynens's suggestion that table-wrapper should be added to all (?) tables. If that's correct, we probably want to automate this via custom Markdown plugin, similarly to custom image render.

created time in 7 days

issue commentv8/v8.dev

List numbers overflow on mobile devices

@tomayac Could you please help out with review - there are two open PRs (#396 and #430) that fix this issue in different ways, but I don't know enough to tell which one is better.

RReverser

comment created time in 7 days

pull request commentv8/v8.dev

Preload dark mode toggle code

@tomayac Just to double-check - you don't observe the issue even though the script is in the bottom? I thought you'd need to put it inside the <head> like you did with preload tag.

tomayac

comment created time in 7 days

pull request commentv8/v8.dev

Preload dark mode toggle code

I think preloading would do the job already.

Yeah, it's just that in this case we seem to unnecessarily duplicate script in two places and depend on browser support for modulepreload (which e.g. Firefox doesn't have).

With script type="module" it would both be slightly simpler and work everywhere.

tomayac

comment created time in 7 days

pull request commentWebAssembly/binaryen

use ECMASCRIPT6 for Closure Compiler

It seems ECMASCRIPT_2015 should enable it.

It might be just for the input support. As far as I can tell from the docs, they still always transpile them for output.

MaxGraey

comment created time in 7 days

pull request commentv8/v8.dev

Preload dark mode toggle code

Oh, interesting. Perhaps we should just split it out into a separate <script type="module" in the same place altogether?

tomayac

comment created time in 7 days

pull request commentWebAssembly/binaryen

use ECMASCRIPT6 for Closure Compiler

Sounds like a good idea to me.

What's still somewhat unclear to me is when to make the switch to ES modules

Does Closure Compiler even finally support modules output? I remember them force-transpiling those regardless of the language, but, admittedly, it's been a while since I looked into it.

MaxGraey

comment created time in 7 days

PR opened GoogleChromeLabs/squoosh

Fixup HQX build

Porting over few more improvements from #777 that can be applied to HQX despite the older Rust version:

  • Removed Cargo.lock from .gitignore (the file itself was added in the original PR, but is still ignored and wouldn't get committed on changes).
  • Removed couple of stray .DS_Store accidentally added in that PR.
  • Added a --locked to wasm-pack build to make sure we rebuild HQX with the same versions from Cargo.lock.
  • Removed separate wasm-strip and wasm-opt -Os steps from build.sh in HQX because they're already included in wasm-pack, and running twice only makes build slower.
+4 -15

0 comment

7 changed files

pr created time in 7 days

create barnchGoogleChromeLabs/squoosh

branch : hqx-build

created branch time in 7 days

delete branch GoogleChromeLabs/squoosh

delete branch : consolidate-cpp

delete time in 7 days

push eventGoogleChromeLabs/squoosh

Ingvar Stepanyan

commit sha d1cff7d84eade6f65b9f7d3f07d133bf2c510f7d

Consolidate C++ builds Use a shared base image with fixed Emscripten version, autotools and optimisation flags for all C++ codecs. Additionally, move build commands for codecs themselves to Makefile - they're already platform-specific, and Make allows for better caching and parallelisation that custom ad-hoc scripts. This is essentially same as #777 but for C++.

view details

push time in 7 days

PR merged GoogleChromeLabs/squoosh

Reviewers
Consolidate C++ builds

Use a shared base image with fixed Emscripten version, autotools and optimisation flags for all C++ codecs.

Additionally, move build commands for codecs themselves to Makefile - they're already platform-specific, and Make allows for better caching and parallelisation that custom ad-hoc scripts.

This is essentially same as #777 but for C++.

(This should be merged after #780.)

+291 -319

0 comment

19 changed files

RReverser

pr closed time in 7 days

more