Page 2 of 2

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Mon Jul 21, 2014 1:03 pm
by Fiery
Should I add more delays between the GTT_LoadBitmap procedure calls, or between the FT_Write and FT_Read calls? I'm a bit confused though, since I assumed after the display returns either eErrorCode_Success or an error code after issuing the Load A Bitmap command, it is safe to do anything with the display. Or the Load A Bitmap command is asynchronous, and returns immediately, and loads the bitmap in the background? And why can it work properly with BMP and JPEG files, but not with PNG files? JPEG is also compressed, so the uncompression phase shouldn't make a difference with PNG...

It would be great to know more about the actual process of how the GTT hardware loads various type of image files, because our LCD designer needs the images to be loaded and drawn without any hiccups. And adding such delays like 500 or 1000 milliseconds between Load A Bitmap commands would cause huge delays when the user wants to put several PNG images on the LCD :( In my test code I used a lot of those sleeps because I've had no better idea how to fix the code -- but the sleeps didn't help at all fixing the eErrorCode_FileNotFound errors.

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Mon Jul 21, 2014 1:56 pm
by Tino
Hi Tamas,

I am currently looking into this for you. I was able to replicate the issue you are seeing and am working to find a solution.

I will post my findings as soon as I can.
Thank you
Martino

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Thu Jul 24, 2014 3:46 am
by Fiery
Thank you for the fix you've sent me, it works just fine now. I appreciate your fast response and efficient way of sorting out issues.

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Thu Jul 24, 2014 5:31 am
by Fiery
Edit: Nevermind, I've found the required info to calculate dpi for GTT LCDs in the hardware manuals. You just have to scan for Dot Pitch in there, and divide 25.4 by the value :) Using that for font scaling makes the text look exactly how I wanted it to.

I'm facing more GTT issues now :) What I'm trying to do is display some text on the LCD, using TrueType fonts. Problem is: I can't seem to calculate the font Pt size from the font size I use on Windows. What I'm trying to achieve is exact per-pixel positioning of text and images, across a 96dpi (standard dpi) Windows screen and the GTT LCDs. So let's say I put a text of "MatrixOrbitalGTT" in the top-left corner of the LCD, using Tahoma font with 40 font size (not Pt, but regular Windows font size setting). Then I put a logo/picture right next to the text, from the right side. In my LCD layout designer I have to put the image on the x = 398 position to make it almost touch the last "T" character of the text. How can I make sure I can see the exact same picture on the LCD, using the Pt font sizing paradigm? Am I right in thinking that I would have to know the actual GTT model (like GTT50A), and its dpi properties to properly calculate the Pt font size from the Windows font size? So for example, on a 800x480 / 5-inch GTT50A I would have to calculate:

fontsize_Pt = fontsize_Windows * dpi_Windows / dpi_GTT50A

Is that formula right? And if yes, then what are the dpi values for various GTT LCDs? Is there a generic formula I can use to calculate it, like "screen_width_in_pixels / diagonal_size_in_inches" ? That would give 160 dpi for the GTT50A, as long as its display size is exactly 5.0 inches. However, using this formula ...

fontsize_Pt = fontsize_Windows * 96 / 160

... doesn't provide the right size of fonts to match my LCD layout designer :( I would have to use this formula ...

fontsize_Pt = fontsize_Windows * 80 / 160

... to get the 99% correct Pt sizes. Maybe the GTT50A is not 160dpi? Please let me know where did I go wrong with that font scaling issue ;)

Thank you for your patience about my hurdles :)

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Thu Jul 24, 2014 8:41 am
by Clark
Hi Tamas,

You're absolutely correct: fonts will be scaled differently on the GTT than your PC, and even on different GTT models, which can be confusing for some. You could calculate dpi to find the correct scaling factor using either method you have proposed.

An inch (25.4mm) divided by dot pitch (0.135mm) and horizontal pixels (800) divided by screen width (4.25inches) will both provide a dpi value for the GTT50A of approximately 188.

Thanks,
Troy

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Thu Jul 24, 2014 9:59 am
by Fiery
Thank you for your reply. One more issue about fonts: I don't think the Get String Extents command works properly, at least not for me. As a test, I've put a text of "CPU gauge" on the top left corner of the LCD, using the standard Windows True Type font of Tahoma, with 16 pt font size, black font colour on red background colour -- although colour shouldn't make a difference. Get String Extents says the displayed text is 202 pixels wide and 41 pixels tall. Then I've tried to put a PNG image on the position of x = 100, y = 41, to see if it falls right below the text or not. And somehow the image cuts into the tail of the "g" characters. Do I have to do some further adjustments on the Get String Extents result, or maybe this is because of a firmware flaw?

BTW, the Get String Extents width result seems to be accurate, so if I put a PNG image on the position of x = 202 and y = 0, the image doesn't cut into the last character of the text. So the issue seems to be limited to the Get String Extents height result.

Re: GTT Protocol Manual Rev 2.1 questions and issues

Posted: Thu Jul 24, 2014 4:04 pm
by Clark
Hi Tamas,

Fonts are a tricky business. I have done some testing here, and while I do not believe there is an error in the data returned from the Get String Extents command, it may not provide all of the data you need.

I have tested by moving my text insertion point and drawing a rectangle around the resulting string. I have tested with letters that include both ascending and descending portions. While the Get String Extents command appears to provide an accurate maximum size measurement it does not take into account the position of the string baseline. Wikipedia has a brief outline of metrics including the baseline here, and additional (non public domain) information can be found with a quick Google search.

The easy solution is to use all capital letters. Alternatively, you can work with the Set Text Insertion Point command with the Font Anchor Style set to Baseline to determine the length of the descenders for the specific font in use and adjust accordingly.

If possible, we will work to clarify, and perhaps add, font metric values to allow a more straight forward user experience.

Thanks,
Troy