Closed Bug 1945872 Opened 20 days ago Closed 17 days ago

[wpt-sync] Sync PR 50492 - Lazy-render Jinja parameters in Canvas WPT test generator

Categories

(Core :: Graphics: Canvas2D, task, P4)

Product:
Core
Component:
Graphics: Canvas2D
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
137 Branch
Tracking Flags:
Tracking Status
firefox137 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

(
URL
)

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 50492 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/50492
Details from upstream follow.

Jean-Philippe Gravel <jpgravel@chromium.org> wrote:

Lazy-render Jinja parameters in Canvas WPT test generator

In the canvas WPT test generator, test parameters can refer to each
other. The code parameter for instance can have a Jinja tag referring
to another parameter ({{ expected_color }} for instance), and that
parameter can in turn have Jinja tags referring to other parameters, and
so on.

This was implemented by repetitively rendering Jinja templates, until
the output of a render pass produces the same results as the input. At
each render pass, parameters would be expanded into the template, and if
that expansion happens to add new Jinja tags, these will be rendered in
the following render pass.

This was inefficient since it required every templates to be rendered
one extra time. This was also fragile and a maintenance burden since we
had to treat some test parameters as special case that need to be
rendered before they can be used. For instance, 'name' or 'desc' could
contain Jinja tags, so we had to pre-render these, just in case. For
performance reasons, we would not do this systematically to all
parameters though, breaking symmetry in feature support.

More importantly though, the multi-render-pass strategy prevented the
use of Jinja macros. For instance:

code: |
{% macro format_color(color) %}
{{- '%d,%d,%d,%d' | format(...) -}}
{% endmacro %}

 @assert pixel 50,25 == {{ format_color(expected_color) }};

expected_color: |
{% macro calculate_color(...) %}
...
{% endmacro %}
{{ calculate_color(...) }}

With the multi-render-pass strategy, the format_color macro would
be evaluated on the first render pass, but it would operate on the Jinja
template source code in expected_color. It really would need to
operate on the rendered result of that child template.

All of the above can be addressed by using an alternative parameter
chaining strategy. This CL adds a new _LazyRenderedStr type, which is
an str that holds a template, but evaluates to the rendering result
of that template when read. By using this type in the Jinja parameter
dictionary, we are automatically rendering parameters when they used by
Jinja. Thus, parameters automatically get rendered in the right order.
In the example above, Jinja would render code, encounter the
parameter expected_color, which would get rendered here and then,
returning that rendering result as expected_color value to be used in
the code template.

Bug: 40207206
Change-Id: I12a9861ae7d94340c4858b34057eb0144a7da67f

Reviewed-on: https://chromium-review.googlesource.com/6203781
WPT-Export-Revision: eed78b11ac627157bf7f3bbbb20b20b9601a4231

PR 50492 applied with additional changes from upstream: a92d5cdd27c657773392e7b8d3d03e797553576f
Component: web-platform-tests → Graphics: Canvas2D
Product: Testing → Core
Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6214a72e024f [wpt PR 50492] - Lazy-render Jinja parameters in Canvas WPT test generator, a=testonly
Test result changes from PR not available.

https://hg.mozilla.org/mozilla-central/rev/6214a72e024f

Status: NEW → RESOLVED
Closed: 17 days ago
status-firefox137: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 137 Branch
You need to log in before you can comment on or make changes to this bug.