rebuildIfDirty walks group_fields like the other per-group code, so a new
group needs no change there. Capacities moves out of Group since it
doesn't depend on the spec. Also updates the ownProps and compute call
sites to the (el, frame) order.
Each group owns its rule buckets, its memo and its cascade priorities, so a
rule only joins the groups it declares something in. Visibility keeps
display, visibility, opacity and pointer-events; overflow and
overscroll-behavior move to a geometry group. A visibility probe no longer
matches overflow-only rules, and its memo entry shrinks to 6 bits.
In Runner, when we're `in_cdp` we reduce the HttpClient poll time to 10ms when
a v8 tells us it has a background task. This is to help ensure we don't linger
too long in HttpClient's poll when v8 has work.
But, 10ms can still be long, especially in a WPT test that's running thousands
of WASM compilation in serial. So rather than having a flat 10ms wait, Runner
will now wait 0-10ms, based on (a) whether the last pump had any tasks and (b)
the number of _ticks since there was task.
This is potentially a temporary solution to having v8 wake the HttpClient when
a task is ready.
A parser created via document.open() is only freed when done/close is called
(or some parse error happens). If close() isn't called, the parser is leaked.
This has the Frame track documents that call open so that, on Frame.deinit(),
it can free any parser still associated with the document.
This is the configuration-half of the Sanitizer API. In a follow up, we'll add
the missing element.setHtml and sanitizer option to the existing setHTMLUnsafe
(as well as the ShadowRoot and Document sanitizer-aware methods).
I'm stealth adding these changes to the log-msg-limit branch/PR because...
This branch reverts a previous intentional change https://github.com/lightpanda-io/browser/pull/2690
which positively impacted memory usage. However #2690 did a couple things, and
changing `comptime msg: []const u8` to `msg: []const u8` was the most
insignificant. So, I was hoping this change would be ok, the real memory gain
of 2690 probably have nothing to do with the comptime message.
BUT, I wanted to make sure, so I re-generated the orderfile on this branch, to
get the CI report for an optimal build. And the memory went +4MB, which seemed
impossible. Turns out my local ../demo was in a weird state from some WebDriver
testing yesterday and nothing was ever executed. So the orderfile I generated
was meaningless.
So, I'm now (a) including optimized orderfiles for this branch and (b) making
regen.sh fail if the bench doesn't seem to successfully run
Comptime msg validation was removed in https://github.com/lightpanda-io/browser/pull/2690
as part of a memory reduction effort. But that PR did more than just remove the
comptime msg (and thus the comptime msg check). So I want to see what the memory
usage is with an ideal orderfile.
logToErased asserts that a log message is at most 30 characters of
plain text, but only in a debug build and only once the line actually
runs. A message on a rare path therefore ships fine and then panics on
whoever first reaches it: `serve --host 0.0.0.0` without
--advertise-host crashed on startup in every debug build, because
"advertising loopback for wildcard bind" is 38 characters.
Every message is a literal, so make the six wrappers take a comptime
msg and apply the same two rules through @compileError. The runtime
check stays as the backstop for the paths the compiler does not
analyse for the current target, and now reads the same constant.
Eleven messages were over the limit; shorten them. The detail already
lives in the kv pairs in each case. renderFailed takes its message as
comptime now, the only call site that passed a runtime one.
Note the check only covers code analysed for the target being built:
the two in Certificates.zig sit in an OS switch prong that Linux never
compiles, and were found by scanning the source rather than by the
compiler.
Adrià Arrufat