more gpu

1 files changed, 25 insertions, 0 deletions

diff --git a/docs/gpu-gradient.txt b/docs/gpu-gradient.txt
index 690b1ac4..533e5498 100644
--- a/docs/gpu-gradient.txt
+++ b/docs/gpu-gradient.txt
@@ -1,3 +1,5 @@
+See the end of this file for a simpler way.
+
 It may or may not be interesting to do gradients with table lookups on
 CPUs, but for GPUs there doesn't seem to be a good way around
 it. There is a potential problem near the borders between two stops,
@@ -35,3 +37,26 @@ are close to a transition so that supersampling becomes
 straightforward. Or maybe not - there is nothing that says we will
 necessarily sample the transition bands, so need to keep track of
 derivatives to do adaptive sampling.
+
+A simpler way to do gradients on a GPU is to convert each color stop
+location to say 10 bits, where 0x1111111111 would be 1, and then
+sample the gradients into an array of size 1024. This way each color
+stop will get an exact sample. (It would be very convenient if the
+applications would specify gradients this way -- for example with a
+byte where 0xff meant 1 and 0x00 meant 0). We still need to deal with
+the case where two color stops have the same location though. Still,
+the idea of three tables will work:
+
+
+array1: [ -  -  -  -  i1 i1 i1 i1 i1 i1 i1 i1 -  -  -  -  -  -  ]
+array2: [ i0 i0 i0 i0 i0 -  -  -  -  -  -  i2 i2 i2 i2 i2 i2 i2 ]
+
+array3: [ 1  1  1  1  0  0  0  0  0  0  0  1  1  1  1  1  1  1 ]
+
+
+where array1 and 2 have LINEAR filering, and array3 has NEAREST.
+
+The shader will look up the coordinate in all three textures, and
+based on the value from array3 it will throw one of the values from 1
+and 2 away and use the other. (When looking up in the third texture,
+it should possibly first round it to the nearest integer).