Repository navigation
Change InkSparkle SPIR-V byte code from static const to a file to prepare for Impeller #99783
Description
Activity
Is there any update on this? My understanding from the discussion on the PR was that that this would be a quick follow-up.
We've discussed this (@clocksmith). A PR that uses a precompiled asset is forthcoming.
May need some quick help on setting this up, but I can take a look
An example of an asset needed for material is the material fonts. The data for the shader can be handled in a similar way. Here's the code in the tool where the fonts are bundled as assets whenever
uses-material-designis in the pubspec:https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/asset.dart#L493
With that wired up, the shader data can be loaded like any other asset. Fetching the data and making a bytebuffer out of it would probably have to be made async:
But the shader transpiling is already async, so that should not cause any difficulties.
cc @goderbauer and @dnfield in case any of that needs clarification.
Ok this looks relatively straight forward. I will try to send something out by tomorrow. Thanks!
Reacted by Zachary AndersonQuestion: what folder should ink_sparkle.spv be placed in? For this WIP, I placed it in a sibling directory of material_fonts, but that is under the root directory bin/cache, which seems wrong.
Stuff in
bin/cacheis populated by the tool downloading data from e.g. google storage. It will get blown away since it isn't part of the repo. I'd suggest putting shaders in the source tree. Maybe inpackages/flutter/lib/src/material/shadersorpackages/flutter/data/shaders. I think we should get advice from @goderbauer for this though.We should not check in binary files to the repo.
Can we store this the same way that the material fonts are stored in a GCS bucket?
Alternatively, can we check in the source code here and compile it at build time?
(or perhaps compile it during the tool build process)
12 remaining items
I believe there's a script that will flag this if we try to add it as a binary asset. We've intentionally made it challenging to add new binary assets to avoid things like this.
We'd never have to remove the asset from the GCS bucket. Maybe there's an argument to make that this should get an exception because it was already in the repo as a binary asset embedded in source code and embedded there in a less efficient manner...
Pending question in #101699
This is done.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on May 20, 2022 - changed the title
[-][Material] [InkSparkle] Change SPIR-V byte code from static const to a file to prepare for Impeller[/-][+][InkSparkle] Change SPIR-V byte code from static const to a file to prepare for Impeller[/+]on May 23, 2022 - changed the title
[-][InkSparkle] Change SPIR-V byte code from static const to a file to prepare for Impeller[/-][+]Change InkSparkle SPIR-V byte code from static const to a file to prepare for Impeller[/+]on May 23, 2022 - changed the title
[-]Change InkSparkle SPIR-V byte code from static const to a file to prepare for Impeller[/-][+]Change `InkSparkle` SPIR-V byte code from static const to a file to prepare for Impeller[/+]on May 24, 2022
Binary is currently here: https://github.com/material-components/material-components-flutter-experimental/tree/fragment-shader-manager/fragment_shader_manager/shaders