I'm guessing that some of this is "off by one" pixel issues related to how the code views pixel line drawing and filling.
Believe it or not there are multiple ways of how to draw pixels that are incompatible with each other.
Different parts of the library code may not all be making the same assumptions as to how it works.
For example there can be different rendering concepts:
- draw a line of N pixels starting here
- draw a line from here N more pixels.
- using a more complex coordinate system methodology which allows composting & aliasing but where the # of pixels draw can vary from N-1 to N+1 depending on base coordinate and the graphic operation.
Believe it or not that 3rd model was/is used by the java awt 2d graphics library:
https://docs.oracle.com/javase/8/docs/api/java/awt/Graphics2D.html
In its model, the coordinates do not map to actual pixels but rather define points in-between the actual pixels.
While this sounds a bit bizarre it does make some things work better/easier when using colored pixels and doing more complex composting, especially when using variable width "pens" for wider than single pixel line drawing.
However, that methodology comes with some very odd (and confusing) quirks in my opinion that can make it difficult to use and prone to errors.
You can and end up with things that don't seem correct like the number of pixels you specify to a fill routine will be different (off by one) than the number of pixels you specify in drawing a line or a shape.
Java AWT considers those to be "normal".
Much of the benefit of rendering this way is not needed in a monochrome pixel LCD environment.
Originally the glcd library (now openGLCD) modeled its API after Java awt API functions and followed its rendering model.
It makes doing higher complex rendering functions that involve fills difficult as they must be aware of these things and account for them.
It is also a total pain to deal with the application (sketch) code as it also has to these differences into account.
When I created openGLCD I got tired of the differences since it didn't really buy anything and often created issues and complaints about it - since it often looks like bugs.
So I changed the openGLCD API & code to always be consistent and use a model of
- draw starting here, and the line length or fill size is EXACTLY the number of pixels you specify.
It makes things so much simpler and less error prone.
So now in openGLCD, lines, shapes, and shape fills all use the same pixel length parameter and can start on the same coordinate.
i.e. you can draw a shape or fill it using the same coordinate and length/size parameters.
Whereas previously if you wanted to draw a shape like a square and fill it not only was the length of the sides you had to specify different but the starting coordinate must be different as well.
This seemingly inconsistent way of specifying things is the way Java awt works!
Also of note, is that circles can be particularly tough. And I have seem issues in code and libraries with respect to drawing and filling circles that create incorrect fills with "garbage pixels" like what was shown in the photos.
These are definitely bugs in the code.
There are also several ways to handle circles.
Most routines specifying a center coordinate then a radius but then what is the radius?
and how is it counted? Does it include the center coordinate or does it extend "radius" pixels from the
center.
i.e. if you specify a radius of 10, is the diameter 19, 20, or 21 pixels? (I've seen all three ways).
This all gets even further complicated if using the java awt coordinate and rendering methodology.
Ironically, in java awt, they did not follow their own coordinate and pixel rendering model for circles and circle fills.
This always bothered me as it seemed like they punted and didn't bother to go in and fix the circle code which made it inconsistent with everything else.
If a library is using the awt coordinate and rendering model, changing this something else to be fully consistent is not as easy as it might sound as it can involve going in and fixing all the higher level API functions and potentially even modifying or tweaking some fill code right in the middle of some Bresenham calculations.
And then lots of existing code that was created the existing methodology will suddenly have rendering issues.
i.e. there is lots of public domain rendering routines that draw shapes or does fills that often use some very clever integer calculations that make assumptions or take into consideration how the lower level line drawing filling works that often have to be tweaked depending on how it may actually work in the library.
i.e. they may assume a awt model or they may not.
The code must be adapted to the way library works and the only way to fix it is by modifying the code at the upper level (the high level function) not the lower levels.
I spent many weeks converting over all the openGLCD functions getting all code to not have rendering issues like what can be seen in the photos posted and updating all the documentation. It is not fun work. I spent lots of time with a magnifying glass looking at pixels during the process.
--- bill
