gdispDrawString() vs gdispFillString()

[Mad River]

What gdispDrawString() is supposed to do?

I tried the following code:

    font = gdispOpenFont("DejaVu*");    
    
    line1 = "abcdefghij";

    gdispDrawString(0, 0, line1, font, White); // 1
    gdispFillString(0, 0, line1, font, White, Black); // 2

"// 2" Works just fine. "abcdefghij" is shown in the display.

"// 1" Nothing happens.

 

Already tried to change between "White" and "Black", still nothing happens when using "// 1".

[wctltya]

Number 2 is overlapping 1

[Joel Bodenmann]

gdispDrawString() draws a string with the given color without clearing the background. Basically every non-character pixel stays untouched. gdispFillString() on the other hand first fills the bounding rectangle of the string with the given background color and then draws the string on top of that with the given foreground color.

The API documentation of those GDISP functions can be found here: http://api.ugfx.io/group___g_d_i_s_p.html

[Mad River]

Quote

Number 2 is overlapping 1

I copy-pasted it wrong!

In fact, I tried only one line at a time:

 

 font = gdispOpenFont("DejaVu*");    
    
    line1 = "abcdefghij";

    //gdispDrawString(0, 0, line1, font, White); // 1
    gdispFillString(0, 0, line1, font, White, Black); // 2

 

@Joel Bodenmann

So, it is exactly how I was expecting it to be.

But for some reason the gdispDrawString() is not showing anything in the display.

It is the only function existing in the gdisp that is not working properly.

 

One quick question: will a horizontal scroll function be included in the library? I only found a vertical one.

[Mad River]

In the gdispDrawString(), I changed this:

g->t.clipx1 = 32768; //x + mf_get_string_width(font, str, 0, 0) + font->baseline_x;

for this:

g->t.clipx1 =  x + mf_get_string_width(font, str, 0, 0) + font->baseline_x; // 32768;

And the function started working.

Is it something to be worried about?

[Joel Bodenmann]

Interesting. That's a change that @inmarket committed. I'm not sure what the story on that is. However, due to how the clipping works that definitely shouldn't lead to the problem that you're experiencing. Especially as that code appears to be working everywhere else.

I'll dive into that and report back. Stay tuned.

[Joel Bodenmann]

So this appears to be a bug. The change of using a constant here rather than actually calculating the string with is okay and preferred at this point (hence the change). However, the constant itself is wrong. The clipx1 field is of type coord_t which is usually (and defaults to) int16_t. This means that the maximum positive value is 32767, and not 32768. In this case it seems like you're experiencing an overflow that gives you an x1 clipping coordinate of -32768 which explains why you don't get any text rendered. I don't have time to run the usually battery of tests right now. Could you please adjust the constant to 32767 and check whether everything is working as expected?

Also, it would be interesting to see whether you get a compiler warning about this. The compiler should definitely inform about the overflow here. What compiler are you using?

Thank you for bringing this to our attention  

[Joel Bodenmann]

Fix pushed to the repository. Thanks again for bringing this to our attention!