Hi all android wave I am writing a new modifier to enable bl

Question

Hi all android wave I am writing a new modifier to enable blur on composables based on a value from shared preferences Could some modifier experts help me with a review Any gotchas I should be aware of thread

Shivam Verma · Answer

```fun Modifier blur = composed val context = LocalContext current val bitmap = ImageBitmap imageResource R drawable blur val tintColor = MaterialTheme colors onPrimary val isBlurEnabled = BlurPreferences context getFlow collectAsStateWithLifecycle initialValue = false drawWithContent if isBlurEnabled value drawContent else drawImage image = bitmap colorFilter = ColorFilter tint tintColor BlendMode SrcIn dstSize = IntSize size width toInt size height toInt ```

Atul Gupta · Answer

I think there is new way to write the modifier using Node system and `composed` is not that performant

Atul Gupta · Answer

Also shouldn t ```val isBlurEnabled = BlurPreferences context getFlow collectAsStateWithLifecycle initialValue = false ``` be withing the remember scope PS I am also new to compose so might be giving some wrong advice

ascii · Answer

Compose already has `Modifier blur` but that s only for A12+ I m assuming yours is intended to be used as a fallback

ascii · Answer

As a general rule don t use `composed` unless you absolutely need to It s attractive to have a black box modifier that just works but you re trading ease of use for performance Both `LocalContext` and `MaterialTheme colors` can be passed in from the calling composable and you don t need to use the `imageResource` composable The only thing that remains then is your blur pref flow Where is it coming from How often does the user change prefs that you need to react to changes Is this modifier used in many places If it absolutely must be a state you may be able to hoist it up and re use it throughout the app

efemoney · Answer

`Modifier Node`s can read composition locals by extending `CompositionLocalConsumerModifierNode` so no need to pass those in They also have a `coroutineScope` so that you can launch coroutines that read your flow I really hope your preferences flow is being produced on a background thread if not you d be reading preferences on the main thread which is where compose and there fore the coroutine scope runs as of today If you extend DrawModifierNode or something like that you can do draw operations like you have so that there should be no need for `composed` modifier at all

Shivam Verma · Answer

> but you re trading ease of use for performance < ascii> Could you please elaborate on what exactly is bad for performance in this design Or are you referring to the fact that `composed` is bad for creating modifiers others thanks for your tips about `Modifier Node` I ll try that out pray