webrender: Bad performance when rendering long list of links separated with commas.

Hi,

I noticed that one page works really slow with webrender enabled. It turned out to be a list of links. It tanks compositor performance and CPU backed to a lesser degree. With 5000 links I get 45ms mean when scrolling on decent CPU. And it spikes to 160ms when selecting text. You can see the attached screenshot for profiler view after little bit of scrolling the page.

Click for screenshot

webrender

It happens when links are separated with commas. Probably matter of having alternating text color or something.

Here is the page that you can reproduce the issue.

<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
	<script>
		for (let i = 0; i < 5000; ++i) {
			const str = (Math.random() + 1).toString(36).substring(7);
			document.body.insertAdjacentHTML('beforeend', `<a href="https://example.com/">${str}</a>, `);			
		}
	</script>
</body>
</html>

Regards, Kacper

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 17 (15 by maintainers)

Commits related to this issue

Auto merge of #3232 - kvark:solid-line, r=gw3583 Render solid line decorations in the opaque pass Fixes #2831 The draw call count drops from 30000 to 60 :) When replaying the WR capture on my Geforc... — committed to servo/webrender by deleted user 6 years ago

Most upvoted comments

Note that my #3232 only addresses the rendering and scrolling issues

Improvement is huge. On 2560x1400 resolution I get around 30fps when scrolling. (i7 5820k and R9 390) but it is no longer visible on first glance in real websites. Still pure CPU rendering is faster tho.

There is more to this case: display lists are humongous, which is seen every time the selection changes. We spend > 50ms just sending the DLs and then about 30ms in the WR backend processing them…

On my end it takes 1800-2200 ms on DL IPC. Basically when anything is selected on page it tanks the performance. Maybe we should keep this issue open for further improvements?

kasper93 on Oct 28, 2018

I think the “IPC” time might just be us choking on https://bugzilla.mozilla.org/show_bug.cgi?id=1435931#c4 which is largely an upstream gecko bug

Gankra on Oct 29, 2018

Picture caching is sort of a universal answer to anything:

look, there is something stupid we do, and it costs us!
oh, but with picture caching we’ll only do it once!

I’d like to see an orthogonal solution here. For instance, what’s stopping us to render all the underline (given that it’s solid rects) in the opaque pass?

kvark on Oct 25, 2018