This entry was posted on September 22, 2011 at 1:50 pm and is filed under Projects. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
I’ve ported mxgui to IL9325-based TFT LCD connected to my Strive Mini board, except touch screen controller (will do this soon). Here are the benchmark results. What do all these figures mean?
Starting Kernel… Ok
Starting Filesystem… Ok
Available heap 53248 out of 63124 Bytes
Monospace text 0.028250 35.39
Variable width text 0.027000 37.03
Antialiased text 0.027500 36.36
Horizontal lines 0.014500 68.96
Vertical lines 0.014000 71.42
Oblique lines 0.098000 10.20
Screen clear 0.013000 76.92
Draw image 0.014750 67.79
ScanLine 0.014000 71.42
ClippedDraw 0.024000 41.66
Clipped text 0.025000 40.00
ResourceImage 0.000000 999.99
And, by the way, I don’t like how the final screen looks like. It seems that it should use antialiased font (white on black) but many pixels in the corners go black. Does it mean that I should finetune the gamma settings?
Well, this is seriously good news 😉
First, an explanation of the benchmark:
Given that the time needed to execute a graphical primitive such as drawing a line is very low, the benchmark measures the time needed to fill an entire screen using that primitive. For example, the text benchmark measures the time needed to fill the screen with text, the image benchmark does the same with images, etc.
The time is printed in the second column and, as it is often used to get an idea of graphics performance, the FPS (frames per second) is also computed as 1/time in the third column.
This gives a hint of how fast will a “real world” application be, as it will use a mix of such drawing primitives.
For the issues with the final screen, my guess is a gamma issue. First, notice that the quality of the antialiasing IS lower than the one used in desktop PCs, since text is printed using a 2bit grayscale. For white on black the resulting colors are black, 33% white, 66% white, white. This has been done to reduce the size of font lookup tables.
To give you an idea of how it should look like, here are two pics of the benchmark final screen running on my stm3210e-eval that has an LCD screen (using an OLED would be unfair, ofcourse)
The numbers of the benchmark you see here are much lower than yours as I’ve run the benchmark code in the external RAM through the fsmc. The second picture is a closeup with a microscope, my personal way of verifying pixel perfect-ness on an embedded device.
As you see, from a distance the glyphs should be “full” without black spots in the lines that composes them (even though the camera blurs everything even more). From a closeup the intensity mismatch becomes visible, but should remain “pleasing”.
By the way, would you mind contributing the display code?
I can give my help adding the StriveMini as an officially supported board, with the proper configuration in settings/Makefile.inc and a folder in arch/cortexM3_stm32, while you could provide the display and touchscreen code for mxgui.
For license issues, your code should be released under the same modified GPL license used in Miosix, just copy-paste it in your sources and replace the line
“Copyright (C) 2011 by Terraneo Federico”
“Copyright (C) 2011 by <your name>”
Let me know if you’re interested.
Oh, yes, your final screen looks much better. I’ll play with gamma tonight and I beleive I’ll find a way to fix the problem.
BTW, will this simple antialiasing work with black-on-white text? And with black-on-gray?
Of course, I’ll contribute the arch directory for the board and the LCD driver. But I need to finish with touch screen driver first. There is a SPI-driven touch controller so it will be easy to do, I hope. Probably it will not need calibration tricks at all.