SKSL verification

[Clark Kent]

in regards to this

    // MakeForColorFilter and MakeForShader verify that the SkSL code is valid for those stages of

    // the Skia pipeline. In all of the signatures described below, color parameters and return
    // values are flexible. They are listed as being 'vec4', but they can also be 'half4' or

    // 'float4'. ('vec4' is an alias for 'float4').

what other verification does skia do?

specifically for depreciation of the old `Create` api and introduction of the new `CreateFor*` api's

as

AndroidUI — Yesterday at 10:51 PM
the old way to create a shader was

var shader_code = SKRuntimeEffect.Create(string);

SKRuntimeEffectChildren children = new(shader_code) { { "src", srcShader } };

using var shader = shader_code.ToShader(false, new(shader_code), children);


the new way to create a shader should be

var shader_code = SKRuntimeEffect.CreateForShader(string);

SKRuntimeShaderBuilder builder = new(shader_code);

builder.SetChildValue("src", srcShader);

using var shader = builder.ToShader();

1. mattleibow — Today at 3:57 PM

   For example this change. We will have to make the new way work, but also not break the old way - somehow
[3:59 PM]
Not sure what we have to do, but we can't take breaking lightly as we have frameworks built on top of us - uno, avalonia , tizen and more

1. The main issue is that unless there is absolutely no way around it, we need to preserve api
2. [3:55 PM]

   Otherwise we break an incredible amount of people
3. [3:56 PM]

   If we want to make changes, this needs to be a slow process of adding a new api and then obsolete the old apis
4. [3:57 PM]

   And then we will have to wait for that to be used
5. [3:57 PM]

   And then later hide or remove

so what options would we have in regards to avoiding api breakage in order to give clients time to migrate to the new api's?