Released: 2026-09-19 / Chromium: 153.0.8010.36 / Language: 日本語 | English
The rendering engine is updated to Chromium 153.
GtkWidget *a = blink_web_view_new_with_profile("tab1");
GtkWidget *b = blink_web_view_new_with_profile("tab2");Until now every WebView in a process shared one profile and cache.
Opening the same
URL in several views served all but the first from that cache, so
only one load
actually happened. That made it impossible to measure what an
additional view costs.
- and _
onlyprofiles/<name>/Cache.blink_web_view_new() keep an in-memory cache as
beforeblink_gtk_get_profile_path() reports does not
changeThe permission-request signal now names 40
kinds instead of 13. The 27 kinds
that used to arrive as "unknown" have names, so an
application can decide based on
what is being asked for.
That includes what a reading application actually uses —
screen-wake-lock (keep the
screen on while reading), local-fonts,
persistent-storage, automatic-fullscreen
and pointer-lock.
execute_javascript could yield
NULL; the implementation nevernullCall blink_gtk_set_gpu_mode() before
blink_gtk_init() and the engine
starts on that path.
blink_gtk_set_gpu_mode(BLINK_GPU_MODE_EGL); /* before init */
blink_gtk_init(&argc, &argv);After initialisation, blink_web_view_get_gpu_mode()
reports the path actually in
use, and the startup log names it ("描画経路=
the request took effect.
Asking for EGL through
blink_web_view_new_with_gpu_mode() did not change
the
path. An external user's report brought this to light.
The rendering path is settled during engine initialisation, together
with the
startup flags handed to the GPU process. By the time a WebView is
created it can
no longer be changed, so the environment variable this API sets has no
effect.
The startup log named EGL in both cases, so there was no way to
tell from
outside whether the request had taken effect.
Delivery counts measured on the same compositor and the same page:
| Form | EGL deliveries | via CPU |
|---|---|---|
BLINKGTK_GPU_MODE=egl alone |
5 | 0 |
new_with_gpu_mode(EGL) + the variable |
5 | 0 |
new_with_gpu_mode(EGL) alone |
0 | 5 |
Without also setting the environment variable, applications asking
for EGL were
running on the CPU pixel path, which has different performance
characteristics
from the zero-copy path.
blink_web_view_new_with_gpu_mode() still works when
called before
initialisation. Asking for a different path after initialisation now
emits a
warning — the engine does not silently draw on another
path.
On systems using a Virtio GPU (virtual machines and
the like), the GPU path
(BLINKGTK_GPU_MODE=egl) stayed blank from start to
finish. Reported by an
external user.
To decide whether a frame is empty, the engine reads the drawn image
from the CPU
side. On this kind of GPU the drawing happens outside the
machine, so that read
sees nothing. Frames that did have content were judged empty and
withheld.
Pages without animation were the most affected: only a handful of
frames are drawn
at startup, and if all of them are withheld the window stays
blank for as long as
it is open. Animated pages appeared partway through.
A frame that reads as all zeros is no longer treated as "empty" but
as "we cannot
tell from here", and display is withheld only when the frame is
genuinely white.
We built an environment with the same GPU device id,
reproduced the problem, and
confirmed the content appears after the fix. On real GPUs
neither the judgement
nor the display changes.
Until now the accessibility tree appeared only if a screen reader was
already
running when the application started. By the time a user turned
on a screen
reader it was too late, and the application had to be restarted.
The engine now notices assistive technology appearing later and
exposes the tree
from that point. The explicit switch (BLINKGTK_A11Y=1)
still works as before.
Closing the window before a page finished loading could
crash. Opening a
book and closing it right away — an ordinary action — triggered it.
Closing
after the page had rendered did not, which made it easy to miss.
The cause was ours. While the page container is being torn down,
a
"navigation finished" notification is delivered, and our handler was
still
looking at something we had already released. We now detach the
handler
before the teardown.
The workaround (waiting for the load to finish before
closing) is no longer
needed.
Reported by an external user. Verified across nine timings,
from 50 ms to
3 seconds, all exiting cleanly.
A second failure with the same trigger (an abnormal-termination
notice instead
of a crash) also stopped reproducing with the same fix.
When drawing through EGL we check whether a buffer is empty. For
frames past
the eighth, that record said "not displaying" while the frame
was in fact
displayed.
Anyone using the record to diagnose a problem would be led
further astray
the more carefully they read it. That happened for about a
month.
The measurement and the decision taken from it are now written as
separate
terms.
Until now our records ended at "the buffer was submitted".
Whether it
actually reached the screen was not recorded.
This build uses the Wayland presentation-time protocol to ask the
compositor.
Every submission gets exactly one outcome: presented (with a timestamp)
or
discarded.
BJGX commit t=391 buf=36 submit=2 op=attach+viewport w=861 h=553 ...
BJGX discard t=399 buf=36 submit=2"The content was empty" and "the content was there but never
displayed" are
different events. The previous records could not tell them
apart, which led
to misdiagnosis.
Nothing is printed by default. Set
BLINKGTK_GX_LOG=1 to enable it. With
it unset, neither rendering nor the display decision changes in any
way.
The format was agreed with an external user beforehand: one event per
line,
key=value only, = as the sole separator. Lines
are joined by the buffer id
and the submission counter.
Alongside the Windows and MIU Darwin ports, the view implementations
now have
platform-neutral names, removing per-platform branches from the shared
code.
No user-visible change.
The release notes shipped with build1 were wrong. They said our
previous
workaround had been removed; it had not, and it is
still present in this
release. The wording now matches the artifact. The program is
otherwise identical to
build1 and typeset output does not change; only the version
string it reports
becomes 1.2.2-build2.
In vertical writing, a line broke half-way when a closing
bracket fell at the
line end. A line with room for 35 characters held only 17, and
because
text-align: justify then spread the remainder, the
inter-character advance
doubled (16px to 33.5px). To a reader that line simply looks
stretched.
This release resolves it. Under the same conditions all 35 characters
fit on
one line.
It does not occur in horizontal writing. The problem
is specific to vertical
writing. Within vertical writing, however, it did not depend on
the
configuration: it appeared with every font we tried (serif,
sans-serif,
Noto Serif CJK JP, Noto Sans CJK JP), with ruby, and with
line-height: normal.
Of 13 configurations, 8 exhibited it; all 8 are resolved in this
release.
The characters spread out only when text-align: justify
is in effect. Without
it the spacing is unchanged and the line simply ends early. Either way
the line
stops half-way.
We reported this upstream (crbug 542686223) and Chromium fixed it.
The fix is in
Chromium 153.
In the previous release (1.2.1 / Chromium 152) we carried our own
workaround,
which improved the count from 17 characters to 34. One
character still moved
to the next line, so it was not complete. That workaround is still
present in this
release; with the upstream fix in effect it did not change the result
within the
range we measured.
We measured how many characters fit on one line. A
single vertical paragraph
(35 characters) was laid out at heights from 544px to 564px in 1px
steps, counting
the characters on the first line, across four fonts, with
text-align: justify,
under software rendering.
We did not measure column filling. How much room is
left at the end of a column
in multi-column layout (whether another line would still fit) is a
different
quantity, and we cannot say it improved in this release. Columns not
filling to
capacity is tracked separately.
The bundled demo answers --version. When reporting a
problem, this single
line identifies the build.
$ blinkgtk_browser --version
BlinkGTK 1.2.2-build6 (Chromium 153.0.8010.36)--help prints the usage and how to specify the URL to
open.
Chromium 153 enables EventTimingMatchingHTML (which
elements event timing
attributes to) by default, among others. For BlinkGTK users the change
that
matters directly is the vertical-writing fix above.
blink_gtk_get_version_full() /
blink_gtk_get_build()) works the same way