GTT Protocol Manual Rev 2.1 questions and issues

GTT TFT Support

Moderator: Mods

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Fiery » Mon Jul 21, 2014 1:03 pm

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.

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Tino » Mon Jul 21, 2014 1:56 pm

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
Martino DeLeon
Matrix Orbital
Technical Support Representative

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Fiery » Thu Jul 24, 2014 3:46 am

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.

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Fiery » Thu Jul 24, 2014 5:31 am

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 :)

Clark
Matrix Orbital
Matrix Orbital
Posts: 864
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Clark » Thu Jul 24, 2014 8:41 am

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
Troy Clark
Design & Development
Matrix Orbital

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Fiery » Thu Jul 24, 2014 9:59 am

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.

Clark
Matrix Orbital
Matrix Orbital
Posts: 864
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: GTT Protocol Manual Rev 2.1 questions and issues

Post by Clark » Thu Jul 24, 2014 4:04 pm

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
Troy Clark
Design & Development
Matrix Orbital

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest