lain,
You are correct in that the v3.0 API does not allow any control over wrapping/scrolling it only allows
choosing scroll direction.
It's been a while since I looked at the low level timing, (I'll have to do that again) but the timing looks
longer than what I would expect.
(but I don't know the size of your font and the text area boundary you are using)
However, it is a good time get this feedback as I was just in the process of creating the list of things for the 3.1 release.
(Was doing this just last night)
Wrapping & Scrolling is one item that I was going back and forth on.
It turns out that it really isn't that difficult so I'll add it to the list of things to put into the 3.1 release.
While the actual code is pretty minor, it more than likely will require a new API call,
as currently there is only a SetTextMode() call and more than likely the way I'll want to do it
will need the creation of a ClearTextMode() call as well. (so capabilities can be turned on or off)
This creates some ripple effects through the documentation but shouldn't be that bad.
In the mean time, for your specific situation, there are some things you can do to potentially speed things up
and eliminate a potential wrap/scroll.
To render characters at the maximum speed, use fonts that are 1 pixel shorter than an 8 bit multiple.
i.e. 5x7, 9x15, etc... also make sure the text area starts on a 8 pixel vertical boundary. y = 0, 8, 16, etc...
(The horizontal boundary does not matter)
Fixed width fonts will render faster than variable width fonts. not because of the variable width differences but
mainly because of the font data format (There is no direct pointer/offset for each individual character's data)
It requires scanning through the character set data and adding up the width of every character prior to the one
to be rendered to locate the data offset for the desired character. (This format existed before the Arduino library was created)
Since the font data is flash it requires going through a access routine since you can't access flash directly given the AVRs
Harvard architecture which adds to the overhead.
Another thing you can do if you have enough SRAM to spare is to turn on the READ cache.
Set the READ_CACHE define in glcd_Config.h and that will eliminate all read accesses to the glcd module
which can really speed up things like scrolling.
Also, if you are using a 1 line text area, and overwriting the line with a new string of the same length
after sending a newline, it is faster to call SetCursor(0,0) before each string and not send the newline
as this way will avoid the line being "scrolled out".
To permanently prevent a wrap and a scroll you can make a one line mod to PutChar().
Change this:
/*
* If the character won't fit in the text area,
* fake a newline to get the text area to wrap and
* scroll if necessary.
* NOTE/WARNING: the below calculation takes into consideration the 1 pixel pad.
*/
if(this->x + width - (isNoPadFixedFont(this->Font)) > this->tarea.x2)
{
this->PutChar('\n'); // fake a newline to cause wrap/scroll
to this:
/*
* If the character won't fit in the text area,
* dump it on the floor
*/
if(this->x + width - (isNoPadFixedFont(this->Font)) > this->tarea.x2)
{
return(0); // dump character on the floor rather than wrap/scroll
This may not be what you really want but it may get you by until there is a way to handle
it properly through the 3.1 API which will allow configuring it on a text area by text area basis.
--- bill