Originally Reported by project member bperrybap, Aug 4, 2010
Currently, there are some issues with boundary checking as not all the calls
check for coordinates being out of bounds.
SetPixels() in particular falls victim of this as it does no checking and can
attempt to read and write off the end of the display.
The is easily noticed by drawing a circle:
GLCD.DrawCircle(0,0,63, BLACK);
You will see a few trash pixels as the DrawRoundRect() routine attempts
to draw its vertical and horizontal lines.
There is code in GotoXY() to prevent out of range parameters.
ReadData() only checks for X values out of range.
WriteData() checks for both but not in all code paths.
SetDot() does full checking.
Checking in SetPixels() is difficult as it is desirable to allow
part of a region to be set and part to be ignored if is off the screen rather
than error off the entire request if any of it is off the screen.
There are few ways to handle this and I will think about it some more
but my thinking at this point is to slightly modify how checking is done so
that upper level functions like SetPixels() no longer have to check bounds if
they don't want to.
This primarily affects the use of the Y coordinate.
I think it will be best to handle it like the X coordinate.
The X coordinate is allowed to fall off the end of the display.
When off the display, all Reads return 0 and Writes are ignored.
The same should be true for Y values that are off the display.
This allows all the higher functions like SetPixels() to keep working
even when attempting to draw off the end of the display.
The Line Drawing routines already use this same mechanism for plotting.
Since SetDot() drops pixels off the display, lines can start or end off the
display and still draw a partial line on the screen.
To make this happen, some changes will need to made to
GotoXY() to always track the X & Y coordinates even when they are off
the screen vs just ignoring the request.
ReadData() will need to also check the Y coordinate.
WriteData() will to also check the initial Y coordinate.
Doing this fix/change will prevent any/all higher level functions from ever
having screen update issues due to out of bounds coordinates.
It also simplifies some of the logic, in some places.
But I still need to think about this, to see the implications on text scrolling
& rapping and of course performance.
Original issue reported on code.google.com by bperry...@gmail.com on 24 Mar 2011 at 7:25
Original issue reported on code.google.com by
bperry...@gmail.comon 24 Mar 2011 at 7:25