The original alpha computation formula had a problem: If something was
drawn on top of a pixel that was already fully opaque, there would be
an overflow in the computed alpha, and the destination alpha would be
truncated to 0 (fully transparent).
In commit 264ba4a9 this formula was replaced with another one, which
did not have overflows but also was not correct.
This commits introduces a new formula, where the rounding errors have
been turned in another direction; drawing a fully opaque pixel on top
of a transparent one would result in a pixel which is almost, but not
fully, opaque. However, this is no problem in practice, since drawing
fully opaque pixels can be achieved with much less code as a special
case, so add that (also improves rendering speed).
The old computation had rounding issues, causing alpha to leak into
the red (usually) component. There's a much easier way to compute it
that does not lead to such problems: What should really happen is that
the two top bits of the A component should be set to 1 (thus adding
75% alpha). So compute it that way for speed and precision.
Formerly, the behavior between when a drawable area was specified and when not
was different in a sense which is not expected. For example, when an empty
textDrawableArea was passed and the text could be drawn outside the 'area'
specified. While when a textDrawableArea covering the whole screen was passed
the text was clipped inside 'area'. Now, the code does follow the latter logic
in both cases.
I am not sure whether this will cause any issues, but a quick check of the
launcher and options menu didn't reveal anything...
This removes the two additional copy steps for rendering when a drawable text
area is specified. Instead it uses Surface::getSubArea to draw directly onto
_activeSurface.
This won't actually make any difference, since the fall through
would do nothing and then reach the break in the default case. But
I think it's less error-prone this way if the code is ever modified.
Formerly values in the gradient and blending code overflowed and thus caused
incorrect colors. Now there's some special case for 32bpp modes, which needs
slightly more operations but assures a correct output.
