Avoid needless bouncing the chip select when drawing glyphs. This
improved performance by around 15% for 24pt fonts.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Add functions to generate shades from a single (usually theme provided)
basic palette colour.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently the empty string cannot be drawn into a fixed width box.
Fix this by adding a special case for empty strings.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently the line drawing code does not draw the final pixel of
straight lines. Thus a line from (0, 0) to (10, 10) finishes on a
different pixel to (10, 0) to (10, 10).
Fix this by removing the spurious subtract one from the end point
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Polar coordinates are very convenient for implementing anything with
radial lines (such as a traditional watch face).
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently all lines are a single pixel wide. To draw wider lines we
must draw two parallel lines with a single pixel offset and this is
a *very* inefficient approach, espeically on ST7789 where we spend
longer setting the clipping window than we do drawing each pixel.
Fix this by constructing a line using a variable sized square rather than
a single pixel. This will "overdraw" (some pixels will be drawn more than
once) but since square blocks can be efficiently transferred to the
display the overdraw is acceptable.
Note: It is a difficult decision whether to maintain the convention that
color is the last argument or to keep compatibility with existing
line drawing tests. This patch opts for the former and fixes up
all uses within the existing codebase.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently there are default argument values for the start and end
coordinates but the defaults don't really make any sense since there
is no reason to prefer the value 0 over any other. Remove them.
Similarly color currently defaults to 0xffff which isn't right. It
should default to the foreground colour.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This is the API:
drawable.line(x1, y1, x2, y2, color)
The function has optimizations for the case of vertical or horizontal lines.
Signed-off-by: Kozova1 <mug66kk@gmail.com>
[daniel@redfelineninja.org.uk: Minor update to commit message]
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
The original approach is *really* bad at drawing vertical lines (it ends
up working a pixel at a time and works the chip select for each one.
Optimize both the pixel fill and the use of the line buffer. The result
is 20% faster for quarter screen fills, 3x for horizontal lines and 6x
for vertical lines.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
sx is measured in pixels (2-bytes) and len(display.linebuffer) gives
a value in bytes so the divisor isn't right.
Whilst we are here let's make sure we use integer division too.
Fixes: #18
If an application crashes let's report it on the device so it can be
distinguished from a hang (if nothing else it should mean we get better
bug reports).
There's a bunch of different changes here but there are only really three
big wins. The biggest win comes from restructuring the 2-bit RLE decode
loop to avoid the inner function (~20%) but the switch to 16-bit writes in
_fill() and adoption of quick_write (e.g. no CS toggling) are also
note worthy (and about 5% each).
