Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 1 | --- |
| 2 | title: 'Skia Coordinate Spaces' |
| 3 | linkTitle: 'Coordinates' |
| 4 | --- |
| 5 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 6 | ## Overview |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 7 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 8 | Skia generally refers to two different coordinate spaces: **device** and |
| 9 | **local**. Device coordinates are defined by the surface (or other device) that |
| 10 | you're rendering to. They range from `(0, 0)` in the upper-left corner of the |
| 11 | surface, to `(w, h)` in the bottom-right corner - they are effectively measured |
| 12 | in pixels. |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 13 | |
| 14 | --- |
| 15 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 16 | ## Local Coordinates |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 17 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 18 | The local coordinate space is how all geometry and shaders are supplied to the |
| 19 | `SkCanvas`. By default, the local and device coordinate systems are the same. |
| 20 | This means that geometry is typically specified in pixel units. Here, we |
| 21 | position a rectangle at `(100, 50)`, and specify that it is `50` units wide and |
| 22 | tall: |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 23 | |
| 24 | <fiddle-embed name='96f782b723c5240aab440242f4c7cbfb'></fiddle-embed> |
| 25 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 26 | Local coordinates are also used to define and evaluate any `SkShader` on the |
| 27 | paint. Here, we define a linear gradient shader that goes from green (when |
| 28 | `x == 0`) to blue (when `x == 50`): |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 29 | |
| 30 | <fiddle-embed name='97cf81a465fdeff01d2298e07a0802a3'></fiddle-embed> |
| 31 | |
| 32 | --- |
| 33 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 34 | ## Shaders Do Not Move With Geometry |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 35 | |
| 36 | Now, let's try to draw the gradient-filled square at `(100, 50)`: |
| 37 | |
| 38 | <fiddle-embed name='3adc73d23d57084f954f52c6b14c8772'></fiddle-embed> |
| 39 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 40 | What happened? Remember, the local coordinate space has not changed. The origin |
| 41 | is still in the upper-left corner of the surface. We have specified that the |
| 42 | geometry should be positioned at `(100, 50)`, but the `SkShader` is still |
| 43 | producing a gradient as `x` goes from `0` to `50`. We have slid the rectangle |
| 44 | across the gradient defined by the `SkShader`. Shaders do not move with the |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 45 | geometry. |
| 46 | |
| 47 | --- |
| 48 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 49 | ## Transforming Local Coordinate Space |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 50 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 51 | To get the desired effect, we could create a new gradient shader, with the |
| 52 | positions moved to `100` and `150`. That makes our shaders difficult to reuse. |
| 53 | Instead, we can use methods on `SkCanvas` to **change the local coordinate |
| 54 | space**. This causes all local coordinates (geometry and shaders) to be |
| 55 | evaluated in the new space defined by the canvas' transformation matrix: |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 56 | |
| 57 | <fiddle-embed name='ce89b326b2bbe41587eec738706bf155'></fiddle-embed> |
| 58 | |
| 59 | --- |
| 60 | |
| 61 | ## <span>Transforming Shader Coordinate Space</span> |
| 62 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 63 | Finally, it is possible to transform the coordinate space of the `SkShader`, |
| 64 | relative to the canvas local coordinate space. To do this, you supply a |
| 65 | `localMatrix` parameter when creating the `SkShader`. In this situation, the |
| 66 | geometry is transformed by the `SkCanvas` matrix. The `SkShader` is transformed |
| 67 | by the `SkCanvas` matrix **and** the `localMatrix` for that shader. The other |
| 68 | way to think about this: The `localMatrix` defines a transform that maps the |
| 69 | shader's coordinates to the coordinate space of the geometry. |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 70 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 71 | To help illustrate the difference, here's our gradient-filled box. It's first |
| 72 | been translated `50` units over and down. Then, we apply a `45` degree rotation |
| 73 | (pivoting on the center of the box) to the canvas. This rotates the geometry of |
| 74 | the box, and the gradient inside it: |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 75 | |
| 76 | <fiddle-embed name='d4b52d94342f1b55900d489c7ba8fd21'></fiddle-embed> |
| 77 | |
Joe Gregorio | 2939993 | 2021-09-17 13:16:00 -0400 | [diff] [blame] | 78 | Compare that to the second example. We still translate `50` units over and down. |
| 79 | Here, though, we apply the `45` degree rotation _only to the shader_, by |
| 80 | specifying it as a `localMatrix` to the `SkGradientShader::MakeLinear` function. |
| 81 | Now, the box remains un-rotated, but the gradient rotates inside the box: |
Brian Osman | 0351d5a | 2021-04-07 16:01:52 -0400 | [diff] [blame] | 82 | |
| 83 | <fiddle-embed name='886fa46943b67e0d6aa78486dcfbcc2c'></fiddle-embed> |