Emilo and Matt suggested to me that we could do full-prerender transform display item on large frame and if we found any blob inside the item, we could do not prerender in subsequent paints.

So that we can tell the prerender decision later in nsDisplayTransform class.

And if there is any blob, we don't prerender it in subsequent paints.

Depends on D73004

Nical, I have a couple of questions about blob in WebRender.

1. Are there good places to tell that we are going to make blob in WebRenderCommdnBuilder? I did add a check in if (itemType == DisplayItemType::TYPE_SVG_WRAPPER) block in CreateWebRenderCommandsFromDisplayList, but should we add where we use
   BlobItemData?
2. Do we also need to avoid prerender nested transforms? Say, <div 'transform animation'><div 'another transform animation'><svg>...</svg></div></div>. I think we need to, but it depends on clip rect of the child transform?

Thanks!

Forwarding the questions to Jeff who knows a lot more about this stuff. I think that right now we basically know when something is going to be a blob image late, when CreateWebRenderCommands (see lots of them nsDisplayList.cpp) returns false. Perhaps we could add another virtual method that query whether something is sure to not fall back to blob images.
SVG is the most common kind of thing that typically falls back to blob images but there are other things. I think that nested transforms need the same kind of treatment as non-nested ones, the main question being, is the transformed blob image going to be much larger than if it was animated on the main therad (for example because we don't get the displayport clip)? If so we probably don't want to use an async transform on it.

1. Like Nical said there isn't really a great way to know if we're going to end up with a blob
2. Perhaps an option for handling the rendering of large transformed things is to just use a max surface size. So if we have some very large thing that's transformed we just draw it at some maximum size and scale up the rest of the way? Either way, when looking for limits on what is acceptible webcompatibile behaviour it might be worth checking what Chrome does.

Great! Thank you Jeff! I am going to check the Chrome's limitation.

Chrome basically uses tiling. Though the each tile size depends on various parameters, on my linux box it's (512, 256) ~ (window width, 256). You can also see tiles' border by enabling "Layer borders" in Rendering section on Chrome's devtools. And the maximum number of tiles seems 10000. There is also a cap of maximum memory usage, the value on my machine is 512MB. I don't know how interact the max tile number with the memory cap though.

Anyways, given that the mimimum tile size (512, 256) is used and they are layouted on (100x100) tiles, then the maximum rasterlized size is (51200, 25600). It's quite huge to me.. Given that Chrome uses tiling, which means they just need to update the dirty tiles, so I am supposing it's not applicable for WebRender?