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.
