[michaelthyregod]

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

• I have read the CONTRIBUTING document
• My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• Breaking change (fix or feature that would cause existing functionality to change)
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Description

Since 0.8.0, nested tables and inline-blocks take time doubling with every level. Each level measures its content with TrialLayout and then lays it out for real, so level n is laid out 2^n times: 6 nested tables take 63 trial layouts, 12 take 4095.

var device = new DefaultRenderDevice { ViewPortWidth = 800, ViewPortHeight = 600 };
var context = BrowsingContext.New(Configuration.Default.WithCss().WithRenderDevice(device));
var html = String.Concat(Enumerable.Repeat("<table><tr><td>", 18)) + "x";
var document = await context.OpenAsync(r => r.Content(html));
new HtmlRenderer().RenderToPng(document, device); // 7.2 s

nested tables	16	18
devel 5a52786	2.6 s	7.2 s
this PR	0.30 s	0.31 s

A trial is laid out on its own (at the origin, with its own floats, positioned and sticky scopes), so the same inputs give the same result within a render. Trials started inside another trial, the ones the layout around them repeats, are now kept in the LayoutContext for the render, like MeasuredHeights: per element, with their inputs (style map, containing width, inherited text style, forced width, atomic/flex item, maxY, measuring mode). Not inside a line-clamped box (its lines are counted), and incremental rendering drops them on every change. 6 nested tables now take 6 trial layouts, 12 take 12. The lookup is a method of its own, so the frame of TrialLayout (on the stack once per nesting level) does not grow.

NestedTrialLayouts_GrowLinearlyWithTheDepth checks this for tables and inline-blocks (RenderMetrics.TrialLayouts).

Benchmarks (AngleSharp.Renderer.Benchmarks, devel 5a52786 vs this PR, P-cores, 3 alternating rounds, median):

	devel	this PR
BuildDisplayList, net10.0	209.9 ms, 58.34 MB	215.8 ms, 58.62 MB
RenderToPng, net10.0	2326 ms, 64.34 MB	2264 ms, 64.63 MB
BuildDisplayList, net8.0	192.5 ms, 58.81 MB	189.1 ms, 59.10 MB
RenderToPng, net8.0	2359 ms, 64.82 MB	2264 ms, 65.10 MB

The benchmark page has few nested trials (40 of 966 are reused), so the time differences are within the spread of a single run (StdDev up to 15% of the mean for BuildDisplayList); the kept trials cost 0.29 MB (0.5%) per render there.

[CLAassistant]

All committers have signed the CLA.

[FlorianRappl]

LGTM!

[FlorianRappl]

Tests fail on MacOS. Not a snapshot issue, but rather a full crash.

[michaelthyregod]

Thanks! The crash is the new test: 12 nested inline-blocks need more stack in a fresh process than the macOS test thread has. With the cache the layout runs so rarely that it stays in the JIT's first tier, whose frames are about 3x larger; devel's 4095 trial layouts get it recompiled along the way. With tiered compilation off, both need the same stack. The test now counts on a thread with a 16 MB stack, so it no longer depends on the platform's thread size.

[FlorianRappl]

LGTM!