Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a écrit :
I wouldn't scale at compile time (as said, storage constrained payloads might not be happy about that).
I wouldn't scale each character up on each access though (we won't hardware accelerate the scaling, and yes, that does get slow - framebuffers aren't always the fastest type of memory and that way the access pattern is the same set of memcpy()s as for any other huge font, so we won't need to deal with "fast fonts" and "slow fonts" beyond basic geometry characteristics), but synthesize a new font in the regular font table at init-time and then use it like any pre- existing font (just that it happened to be added after load).
As it turns out, no scaling in memory is required, either at build time or run time. This is thanks to the fact that the font is coded with each bit representing a filled or blank pixel, so the font has to be accessed bit-by-bit to draw it. I simply modified the access logic to use a scale factor and I don't think it will impact performance much (that's still two extra divisions for each pixel though).
The changes are up for review at: https://review.coreboot.org/#/c/20708/ https://review.coreboot.org/#/c/20709/ https://review.coreboot.org/#/c/20710/
Thanks everyone for the feedback and happy review!
2017-07-17 21:47 GMT+02:00 Julius Werner jwerner@chromium.org:
I agree with most of what Patrick said, I think dynamic scaling to integer multiples may be best. Scaling the font up at compile-time seems like unnecessary bloat to the binary (although I'm not sure, how big are these fonts?). If you do want to include them at compile time, you may as well include a real larger font rather than just a scaled one.
Le dimanche 23 juillet 2017 à 16:21 +0300, Paul Kocialkowski a écrit :
Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a écrit :
I wouldn't scale at compile time (as said, storage constrained payloads might not be happy about that).
I wouldn't scale each character up on each access though (we won't hardware accelerate the scaling, and yes, that does get slow - framebuffers aren't always the fastest type of memory and that way the access pattern is the same set of memcpy()s as for any other huge font, so we won't need to deal with "fast fonts" and "slow fonts" beyond basic geometry characteristics), but synthesize a new font in the regular font table at init-time and then use it like any pre- existing font (just that it happened to be added after load).
As it turns out, no scaling in memory is required, either at build time or run time. This is thanks to the fact that the font is coded with each bit representing a filled or blank pixel, so the font has to be accessed bit-by-bit to draw it. I simply modified the access logic to use a scale factor and I don't think it will impact performance much (that's still two extra divisions for each pixel though).
The changes are up for review at: https://review.coreboot.org/#/c/20708/ https://review.coreboot.org/#/c/20709/ https://review.coreboot.org/#/c/20710/
Thanks everyone for the feedback and happy review!
I forgot to mention: I tested this on kevin (with and without scaling) and the result looks great!
2017-07-17 21:47 GMT+02:00 Julius Werner jwerner@chromium.org:
I agree with most of what Patrick said, I think dynamic scaling to integer multiples may be best. Scaling the font up at compile-time seems like unnecessary bloat to the binary (although I'm not sure, how big are these fonts?). If you do want to include them at compile time, you may as well include a real larger font rather than just a scaled one.
-
Paul Kocialkowski