No, no Tectu. Speed ain't an issue with these micros! Plus everybody ain't lucky to have a complete free 16 lines port. Imagine that guy who uses a 64-pin micro for connecting to LCD.
I am just looking forward to see how fast can these beasts get with the proper fuel!
Abhishek
text rendering
Re: text rendering
In the post 'picture rendering', Anubirux had posted about adding Unicode and multiple languages support. I'm replying to it here, as it pertains to text rendering.
The point is, our text rendering system currently in use won't be exactly ready for that kind of a thing. It currently is just like drawing a bitmap on screen, except the fact that the bitmap is monochrome and compressed to 1 bit per pixel. Doing unicode stuff requires a lot of information to store and draw the char. E.g. in Hindi, my mother tongue, when drawing two characters, one character is drawn on top of the previous char! Similarly with accent on characters, e.g. café, and so on
Of course the Chinese have developed some sort of workaround. In one project of theirs using graphic LCD and STM32, I saw that they used a SST25V016 chip on board and copied their char table from SD card onto it on the first run. They call it 'HzLib'.
Also, one more thing that our code doesn't support now is font size scaling. This means that font size in pixels is fixed at font generation time. If you need a bigger font, you have to generate it separately and it'll take up more flashspace (each font currently uses about 1.5-2 Kbyte and that too for only 96 glyphs! Imagine the size if I support, say, just some odd 30000 glyphs for unicode). Would be great if I define a single font and can render it in various sizes, bold, italic, etc.
Anti-aliasing for graphics and text sounds a little far-fetched idea right now, but I guess we could at least give it a shot someday. Will certainly look good and be the first of its kind in an open-source embedded graphics library offering. I would like to invite developers who have had experience with 2D computer graphics. Maybe you could help us enrich our library.
I stumbled upon libfreetype, Link: http://www.freetype.org/ for a solution. But have no idea if it is usable and practical on an STM32. Even if somehow the code compiles, what space it would take up and what would be the speed is something questionable. What does the community have to say?
I guess we stick to basic ASCII support for now (96 chars for now, If required, maybe extend upto 256-byte table), until we find or code something better.
Abhishek
The point is, our text rendering system currently in use won't be exactly ready for that kind of a thing. It currently is just like drawing a bitmap on screen, except the fact that the bitmap is monochrome and compressed to 1 bit per pixel. Doing unicode stuff requires a lot of information to store and draw the char. E.g. in Hindi, my mother tongue, when drawing two characters, one character is drawn on top of the previous char! Similarly with accent on characters, e.g. café, and so on
Of course the Chinese have developed some sort of workaround. In one project of theirs using graphic LCD and STM32, I saw that they used a SST25V016 chip on board and copied their char table from SD card onto it on the first run. They call it 'HzLib'.
Also, one more thing that our code doesn't support now is font size scaling. This means that font size in pixels is fixed at font generation time. If you need a bigger font, you have to generate it separately and it'll take up more flashspace (each font currently uses about 1.5-2 Kbyte and that too for only 96 glyphs! Imagine the size if I support, say, just some odd 30000 glyphs for unicode). Would be great if I define a single font and can render it in various sizes, bold, italic, etc.
Anti-aliasing for graphics and text sounds a little far-fetched idea right now, but I guess we could at least give it a shot someday. Will certainly look good and be the first of its kind in an open-source embedded graphics library offering. I would like to invite developers who have had experience with 2D computer graphics. Maybe you could help us enrich our library.
I stumbled upon libfreetype, Link: http://www.freetype.org/ for a solution. But have no idea if it is usable and practical on an STM32. Even if somehow the code compiles, what space it would take up and what would be the speed is something questionable. What does the community have to say?
I guess we stick to basic ASCII support for now (96 chars for now, If required, maybe extend upto 256-byte table), until we find or code something better.
Abhishek
Re: text rendering
Hello Abhishek,
I'd really like if you would finally stick to the textrendering stuff. When you do that, you could get your own files (text.c and text.h).
Having scaling fonts would be one of my greates wishes. Bold, Italic etc. etc. would be used later.
I would be very very thankful when I have some scalable fonts.
If you want to keep working on this stuff, create the files, do whatever you want. I'd suggest you keep the current font rendering inside glcd.c and do your lcdDrawString_test() inside the glcd.c. This way we can keep using the current working functions.
~ Tectu
I'd really like if you would finally stick to the textrendering stuff. When you do that, you could get your own files (text.c and text.h).
Having scaling fonts would be one of my greates wishes. Bold, Italic etc. etc. would be used later.
I would be very very thankful when I have some scalable fonts.
If you want to keep working on this stuff, create the files, do whatever you want. I'd suggest you keep the current font rendering inside glcd.c and do your lcdDrawString_test() inside the glcd.c. This way we can keep using the current working functions.
~ Tectu
Return to “LCD Driver and Graphic Framework”
Who is online
Users browsing this forum: No registered users and 3 guests