The vvalue and hvalue uniforms are only used to decide whether we
should do fade the edges or not based on the fade_edges uniform.
The result does not change accross fragments so there is no reason
to recompute it for every fragment (pixel) so just split the edge
fade into two uniforms and compute the "should we fade the edges"
boolean once for every direction (when setting the uniforms) instead
of for every single fragment twice.
This reduces the number of uniforms as well as the the number of instructions
which are limited on older hardware. It should also be more efficent.
https://bugzilla.gnome.org/show_bug.cgi?id=708007
This doesn't (or shouldn't) change the visual appearance of the fade
effect, but does do all the testing math inside the shader, rather
than on the CPU. This will make fading the offset much easier in
the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689249
Instead of doing complex computations in the shader just pass in the correct
fade area (taking padding, scrollbars and rtl into account) and just work
with that in the shader.
That fixes a bug where we would fade the scrollbar when padding is present.
https://bugzilla.gnome.org/show_bug.cgi?id=659159
Only skip the areas of the scrollbars when they are invisible
and add take the horizontal scrollbar into account as well
when calculating the faded area.
https://bugzilla.gnome.org/show_bug.cgi?id=651866
The number instructions in a shader is limited to 64 on r300 hardware,
the fade shader in StScrollViewFade was ending up using 97 instructions
which is way over the limit.
So refactor the shader to use less instructions by precomputing as many
values as possible outside of the conditionals. The resulting shader
ends up using 34 instructions which is well within the hardware limits.
https://bugzilla.gnome.org/show_bug.cgi?id=644589
The vertical scrollbar is located on the left in RTL locales, so
pass an additional parameter to the shader which indicates the
locale's text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
