From 9894454f57e6e0a98754ef2f2be6406fa7db90ca Mon Sep 17 00:00:00 2001 From: Brian Osman Date: Mon, 25 Sep 2023 20:17:11 +0000 Subject: Fix "fancy" characters in RuntimeShader Javadoc comments Change-Id: I3ab2ce64ee7dae627f27dc1096cf0feb2346b80b --- graphics/java/android/graphics/RuntimeShader.java | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'graphics/java/android') diff --git a/graphics/java/android/graphics/RuntimeShader.java b/graphics/java/android/graphics/RuntimeShader.java index 3e6457919031..78d257f86613 100644 --- a/graphics/java/android/graphics/RuntimeShader.java +++ b/graphics/java/android/graphics/RuntimeShader.java @@ -49,11 +49,11 @@ import libcore.util.NativeAllocationRegistry; * possible antialiasing logic for border pixels). *
  • Logic for the {@link Shader}, {@link ColorFilter}, and {@link BlendMode} on the * {@link Paint}.
    • - *
  • Color space conversion code, as part of Android’s color management.
    • + *
  • Color space conversion code, as part of Android's color management.
    • * * *

    A {@link RuntimeShader}, like other {@link Shader} types, effectively contributes a function - * to the GPU’s fragment shader.

    + * to the GPU's fragment shader.

    * *

    AGSL Shader Execution

    *

    Just like a GLSL shader, an AGSL shader begins execution in a main function. Unlike GLSL, the @@ -78,10 +78,10 @@ import libcore.util.NativeAllocationRegistry; * {@link ColorSpace} for an AGSL shader is defined to be the color space of the destination, which * in most cases is determined by {@link Window#setColorMode(int)}.

    * - *

    When authoring an AGSL shader, you won’t know what the working color space is. For many + *

    When authoring an AGSL shader, you won't know what the working color space is. For many * effects, this is fine because by default color inputs are automatically converted into the * working color space. For certain effects, it may be important to do some math in a fixed, known - * color space. A common example is lighting – to get physically accurate lighting, math should be + * color space. A common example is lighting - to get physically accurate lighting, math should be * done in a linear color space. To help with this, AGSL provides two intrinsic functions that * convert colors between the working color space and the * {@link ColorSpace.Named#LINEAR_EXTENDED_SRGB} color space: @@ -93,7 +93,7 @@ import libcore.util.NativeAllocationRegistry; *

    AGSL and Premultiplied Alpha

    *

    When dealing with transparent colors, there are two (common) possible representations: * straight (unassociated) alpha and premultiplied (associated) alpha. In ASGL the color returned - * by the main function is expected to be premultiplied. AGSL’s use of premultiplied alpha + * by the main function is expected to be premultiplied. AGSL's use of premultiplied alpha * implies: *

    * @@ -101,7 +101,7 @@ import libcore.util.NativeAllocationRegistry; *
  • If your AGSL shader will return transparent colors, be sure to multiply the RGB by A. The * resulting color should be [R*A, G*A, B*A, A], not [R, G, B, A].
    • *
  • For more complex shaders, you must understand which of your colors are premultiplied vs. - * straight. Many operations don’t make sense if you mix both kinds of color together.
    • + * straight. Many operations don't make sense if you mix both kinds of color together. * * *

    Uniforms

    @@ -224,7 +224,7 @@ import libcore.util.NativeAllocationRegistry; * shader uniform is undefined if it is declared in the AGSL shader but not initialized.

    * *

    Although most {@link BitmapShader}s contain colors that should be color managed, some contain - * data that isn’t actually colors. This includes bitmaps storing normals, material properties + * data that isn't actually colors. This includes bitmaps storing normals, material properties * (e.g. roughness), heightmaps, or any other purely mathematical data that happens to be stored in * a bitmap. When using these kinds of shaders in AGSL, you probably want to initialize them with * {@link #setInputBuffer(String, BitmapShader)}. Shaders initialized this way work much like @@ -237,7 +237,7 @@ import libcore.util.NativeAllocationRegistry; * *

    In addition, when sampling from a {@link BitmapShader} be aware that the shader does not use * normalized coordinates (like a texture in GLSL). It uses (0, 0) in the upper-left corner, and - * (width, height) in the bottom-right corner. Normally, this is exactly what you want. If you’re + * (width, height) in the bottom-right corner. Normally, this is exactly what you want. If you're * evaluating the shader with coordinates based on the ones passed to your AGSL program, the scale * is correct. However, if you want to adjust those coordinates (to do some kind of re-mapping of * the bitmap), remember that the coordinates are local to the canvas.

    -- cgit v1.2.3-59-g8ed1b