Remove GlidePainter in favor of Modifier nodes / Flows

[sjudd]

Using a custom Modifier node instead of a Painter follows a recommendation from the Compose team. It will allow us or library users to compose Glide's modifier in the future for animations of other effects. For now we do not actually expose the Modifier directly.

This change adds a GlideSubcomposition that uses' Glide's flows integration to allow subcomposition based on image load state. Subcomposition allows us to deprecate the expensive Composable placeholder variants and also allows users to implement complex layouts or animations.

In a subsequent change we'll explore adding a default crossfade and/or exposing the Glide modifier node so that users of the library can compose modifiers themselves.

[lelandrichardson]

why make these lateinit? the only place you are constructing this you already have all of these values.

[sjudd]

This just saves some duplicate code vs:

val glideNode = GlideNode(size, scale, alignment)
glideNode.onNewRequest(size, scale, alignment, ...)

You could remove the onNewRequest part entirely, but then you're starting a request in a constructor and refactoring that code to be less duplicative. Lesser evil really.

[lelandrichardson]

you should make sure that all of the classes you are using here have sensible equals functions. The GlideNodeElement will be reallocated on recompositions and if nothing for this image has changed you want this element to compare equals with the one created in the previous composition. It is only when these elements are not equal that update will get called

[sjudd]

Done, thanks for pointing this out!

[lelandrichardson]

consider handling the case where alignment/colorfilter/etc change but the requestBuilder does not. In this case we can just invalidate draw or layout but not initiate an entirely new request

[sjudd]

Done

[lelandrichardson]

currently you are not really influencing layout at all here, as you are just assuming the size of your children and placing at 0,0.

Ideally you would look at the drawable's intrinsic size or the size specified by resolvableGlideSize and take up that size here. However consumers are supposed to specify the size of the image they want, here is where you should use it. Then inside of draw you can just draw the image to take up the full amount of space allocated to it.

Additionally, I think if the user did not tell you what size they wanted, a sensible default would be to occupy the space given to you (constraints.maxWidth), and maintain aspect ratio.

[sjudd]

Yeah this is interesting. We really want to occupy the size specified by the Modifier, and ideally nothing else.

If we base the layout on the size of the image you load, then your layout is likely to shift when the image load completes, which is ugly. You could fix that by providing a specific size to Glide, but if you can do that you might as well just do it in your layout instead. Moreover you may very well want to load an image that's smaller than the layout size to save memory or reduce jank.

With all that said, can I simply rely on other modifier attributes to specify an explicit size? If I use maxWidth, will that override any sizing information provided by Modifiers earlier in the chain?

[lelandrichardson]

This probably deserves a full conversation along with some examples, but.... i think there's more that you should do here than you are currently probably regardless.

I think a reasonable behavior would be:

1. if fixed constraints come in you should honor that size
2. if width is constrained and height is not, or vice versa, you should fill to that constrained width/height and utilize the aspect ratio of the image to further constrain the other

[sjudd]

Thanks! I've switched to using the constraint's max dimensions. I filed #5234 to follow up. I think (hope) this is pretty similar to what we had before, so ideally we can tackle more complicated layout issues in a subsequent change.

[TWiStErRob]

@sjudd Are you aware that this change could break compilation of Kotlin code?

Example fail:
https://github.com/TWiStErRob/net.twisterrob.colorfilters/actions/runs/5942409261/job/16115335917?pr=221#step:5:286

And corresponding code:
https://github.com/TWiStErRob/net.twisterrob.colorfilters/blob/0c85d9c/feature/image/src/main/kotlin/net/twisterrob/colorfilters/android/image/BitmapKeeper.kt#L111