Sounds great. How are you going to handle text rendering? I guess you are not going for truetype fonts.. Then maybe use utft fonts, just because they already exist and there are couple of fonts already available..
Yes, For now I'm going to take the easiest route for font data, utft and u8glib are my first choice for this. My main focus is getting pixels to the display as fast as possible. I've been thinking about a vector style font which would be my own interpretation of a truetype font just without control point distortion hints, or very limited hints. Even still, having a pixel map decompressed from program memory might possibly be faster.
From observation, vector style fonts may be faster for larger font sizes, as a new line algorithm that is suitable for the display can calculate multiple pixel runs, but will need a transformation to screen space. Whereas pixel maps don't need calculating but may not be able to benefit from runs.
Or are you planning on going with a slimmer design for that too?
Maybe if suitable, slimmer/smaller isn't really my goal, the design aspects of my library are selected on how well they perform. If a handful of extra bytes will increase performance dramatically, then I'll go for the larger. But don't worry, I have plans for a full config where you can select what parts are small ( code reuse ) and what parts are allowed to trade off size for speed ( specific routines for different drawing functionality).
And on a note for the future,
I also dug out my second display, which turns out to be a HX8347A?? ( TFT_320QVT ). Once the ball is rolling I may look into supporting a few other displays, however this may be an unrealistic move as my library is tailored to the SSD1289. It really seems like a few manufacturers have the monopoly on TFT production like the TV market. Same screens, different firmware/driver.
I'm gonna hit post now as lack of sleep will cause me to keep rambling on for pages. Its nice to see a lot of interest, I'm keen to see what creations people will cook up.
