Currently the final word of wrapped text will always appear as a single
word on its own line. Fix this by rearranging the break cases to avoid
searching for the most recent space when we get to the end of the text.
Fixes: #230
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
wasp-os uses an drawing optimization technique to automatically place
a single pixel line on the right of glyphs when rendering them. This
results in a change to the bounding box for a rendered string (by adding
a single pixel on the right of the final character). Fix the bounding box
calculations accordingly. Among other things this eliminates graphical
artifacts when rendering labels in 2048.
Fixes: #203
Fixes: 58b5c0378e ("draw565: Optimize the string drawing")
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently there is a redundant fill operation issued for every character
drawn. This was added to draw the background colours correctly but the
change did not account for the optimized character rendering in
_draw_glyph().
This results in ~15% performance improvement for character rendering
Fixes: cc34c5d46d ("draw565: Fix wrong background color of strings")
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
Currently, if the line wrapper attempts to break a line on a space and
that space character is outside the bounding box, then we generate an
over-long line.
Fix this by handling line break generation *after* we have checked the
length of the current line.
Fixes: #193
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
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).
