Hmm TBH not a big fan of triggering a repaint based on DPR (and the web-only markNeedsRepaint). What if I have a paragraph inside of a Transform widget (something like InteractiveViewer)? When I zoom in on the text would it appear blurry due to the pre-rasterization? Is it possible to do this based on the scale value of the CTM?

You're right, the paragraph will look blurry if it's scaled by a Transform or InteractiveViewer. There are two concerns I have with using the value of CTM:

1. We can't listen to CTM changes and force a repaint. If I understand correctly, CTM is only available during the paint phase, so if the framework skips painting altogether, we won't detect a CTM change.
2. During a scale animation, it may be prohibitively expensive to regenerate the image on every frame. So we would need to throttle it in some way.

Fixing the DPR case is more straightforward and more valuable because it affects all apps.

What do we do if there is no MediaQuery ancestor?

At the time you asked this question, the answer would've been: We default to 1.0.

Now the answer is: We try to get the DPR from the nearest View ancestor, or default to 1.0.

1. We can't listen to CTM changes and force a repaint. If I understand correctly, CTM is only available during the paint phase, so if the framework skips painting altogether, we won't detect a CTM change.

I think this is doable using a composition callback (although there is going to be an one-frame delay if the text must be rasterized in a paint call, in which case the markNeedsPaint must happen in a post frame callback), example:

2. During a scale animation, it may be prohibitively expensive to regenerate the image on every frame. So we would need to throttle it in some way.

I would think the text needs to be re-rendered when the CTM changes on non-web platforms too? If that's the case is the problem that we usually do rasterization on the raster thread so it doesn't block UI events (does the web engine have a dedicated raster thread?) but for WebParagraph it has to be done on the dart UI thread because it happens in RenderObject.paint?

Oh according to gemini the glyphs will be cached (using the physical size as one of the cache keys).

Fixing the DPR case is more straightforward and more valuable because it affects all apps.

That makes sense but I think Transform + Text / EditableText are a very common widget combinations that this fix does not account for. On both iOS and Android there's this loupe / magnifier thingy that would show up over the text in a text field.

(On a different note is there a place that I can read more about how WebParagraph works?)

Should we do something here that is similar to how the native engine handles its raster cache? When the native engine paints a picture in a scene, it may cache the rasterized picture so it doesn't need to re-rasterize it if it hasn't changed. But when it caches the rastered picture, it stores the current transform matrix. That way it can invalidate its cache if the transform matrix changes (with, IIRC, some checks to make sure that it didn't just do a translation). Could we do something similar with the cached WebParagraph rasters?

@LongCatIsLooong @harryterkelsen thank you both for bringing up good points! I created an issue for better CMT handling: #188025

autosubmit label was removed for flutter/flutter/186968, because The base commit of the PR is older than 7 days and can not be merged. Please merge the latest changes from the main into this branch and resubmit the PR.