dc42:
bperrybap:
Well, I did have a look. There really isn't anything that is "easy". What you are seeing is mainly the inefficiency of the
variable font format itself. (there are much faster ways to store and lookup the font data but it does require a bit more flash space)
With the current variable font format, to locate the data position for a character you have to
to add up the width of each previous character in the font. It is time consuming, especially on a Harvard Architecture
chip like the AVR since you have to call access functions. That is why you see each character taking longer and longer
to render. Each lookup and font width add for each character along the way
adds about 3us or so to the overall rendering.I think it would be well worth using 1 additional byte of flash per character by ditching the byte count and instead having a table of pointers to the start of the data for each character, plus one extra pointer to enable the byte count of the last character to be calculated.
As a short term improvement, you could consider caching the address of the data for the character that is half way through the table, giving you an alternative place to start searching from.
I like the idea about having an offset value for a character that is half way through the table
This is an interesting idea that I may look further into as that can be calculated runtime and
saved in RAM as the font is selected. It also does not require modifying the existing font data format.
As far as font formats go, let me start of by saying I am not a fan of the current variable font data format.
Michael and I were painfully aware of its issues and limitations when we moved forward with it going into v3.
It existed before I started working on the glcd library and even before Michael converted
Thiele's original C library to C++ for Arduino.
There are other issues with the variable font data format that are also irritating and also cost time,
like the residual bits in a font data byte when the font is not exactly a multiple of 8 bits.
The bits in the font data are shifted the wrong direction for aligning with the glcd page byte.
(This is different from how bits are stored for fixed fonts and bitmaps)
This causes additional code and checks to have to be done, while rendering,
to detect when the last byte in a column is being rendered
and to shift the bits around when the font is a variable font and not a multiple of 8 bits in height.
Michael and I had some long discussions about changing the font data format to at least get rid of the incorrectly shifted bits.
I would be nice for rendering in that all the rendering would then
be the same whether the "glyph" was a fixed font, bitmap, or variable font.
The issue early on of the v3 development was that it would break compatibility with ks0108/glcd v2 library
since none of the v2 fonts would work and a major goal of v3 was backward compatibility with v2.
Having a new font format also means re-doing the fontcreator2 JAVA app to be able to generate the new format.
While its not that bad, we opted not to do that for v3.
With respect to the current variable font format, there is no "byte count" for each character.
The data byte for each character is the width of the given character. I assume that is what you meant.
(byte counts and widths are not the same for fonts that are taller than 8 pixels)
I didn't follow your comment about: "plus one extra pointer to enable the byte count of the last character to be calculated".
I assume you meant that the width could be replaced with 16 bit offset values.
And that the width could be back calculated fairly easily knowing the address of the "next" character
and the height of the font.
But it does require and offset value for a "next" character just after the real last character in the table.
Definitely worth considering going forward.
There is also the possibility of having the width and formatting information inside the "glpyh" data.
So the offsets point to a "glyph" and the glyph data has all the needed sizing and leading information
which is a closer match to some of the other font formats used in Operating systems.
I really want to get away from this font format. I also want to be able to either directly use BDF format or
write a small script/tool that can convert from BDF fonts to the embedded format.
That will instantly allow the creation of hundreds of fonts - which will ease the pain of people
having to deal with the loss of their existing font formats should the font data format be changed.
Yes it would be possible to support multiple formats, but that takes extra code since all the rendering for
all the formats would have to exist and be selected runtime
based on the font. It also adds to the maintenance and support load of the library.
There are several other issues such as the current way the font data is compiled & linked in that needs to be resolved.
Currently they are all "static" data arrays that are all compiled in and the linker removes
out the unused fonts.
This creates real problems for implementations that use more than a single source code module.
There are many ways to resolve this but most won't work with the Arduino IDE and its goofy way
of doing things.
I have many ideas and things that could be done, it is a matter of trying to pick the highest priority
items moving forward that can offer the best trade-off of new & improved functionality and backward compatibility.
--- bill