Strange redraw strobing/flashing - TFT_eSPI/ESP32/ILI9341

[loopyengineeringco]

Hi guys

I'm using TFT_eSPI/ESP32/ILI9341. Using the latest available version of guislice and TFT_eSPI and taking advantage of the new image push code.

I have a hardware button toggling the visibility of the glowing image which is on top of the non-glowing version.

But as you can see, the drawing of the image tile isn't clean, it seems to clear the image with white first.

Is this a hardware limitation?

Apologies if this is more a TFT_eSPI question, I thought I'd ask you guys first as you're super knowleadgeble in this.

I tried all the SPI speeds from 10mhz to 80mhz, behaves the same just the angle of the diagonal line changes slightly (&is a little wobbly at 80mhz :-)).

It also seems to happen when popping up a new page, not just drawing images from flash. Feels like an e-paper display thing, where the pixels are flashed before the screen is filled with the correct pixels.

Any ideas how to fix/work around this? Thanks for any pointers!

[ImpulseAdventure]

Hi —

Can you confirm a couple things for me:

• 1: Is gslc_SetBkgndColor() called in your sketch? If not, can you set it to GSLC_COL_BLACK?
• 2: What overlapping elements exist on this page at the location of the button? Is it just the background image and then the image element with toggling visibility? Or do you have the background image, a non-glowing image and then a glowing image (with toggled visibility)? If the latter, I recommend just using a single image and then toggling the glow state rather than using another image with toggled visibility.
• 3: For the overlapping image, can you ensure the FillEn is set to false? ElemSetFillEn()
• 4: Lastly, if you add #define DBG_REDRAW to your config, it will be much clearer to see what redraw regions are being triggered. This provides two outputs: a visual feedback of the redraw process (slowed down) as well as debug coordinates to the monitor.

Looking at my code, I think I should probably be defaulting the image to have its fill attribute disabled. This might eliminate an extra background fill as in (3).

If you are able to attach this particular sketch (with the accompanying images), I may be able to carry out some of the tests myself.

Thanks!

[loopyengineeringco]

Thank you for the points @ImpulseAdventure - 'gslc_ElemSetFillEn(&m_gui,imageElement,false)' indeed masked the issue so it now wipes with the background colour instead of white: (I think it's ghosting just because of pixel lag)

• 1: gslc_SetBkgndColor() was called in the original example yes.
• 2: At that location - 2 images, no background image. Unlit image bottom, lit image on top. I might try as you suggested - unlit state being a whole background image, and lit image tile on top toggling it's visibility.
• 3: After trying gslc_ElemSetFillEn(&m_gui,imageElement,true), there was no change (still white flash). gslc_ElemSetFillEn(&m_gui,imageElement,false) masked the issue where the wipe is now the background colour, which is fine in my use case. I checked the builder and there isn't a fill setting for image elements. So I think it was defaulting to True for me.
• 4: Great tip, will definitely employ this, thanks! At the moment, the redraw region is quite visible when it's large, so it's pretty obvious, but I imagine with a faster display/mcu this is super handy

I wanted to ask first, in case there's something easy to try before uploading everything! If you'd be so kind as to take a look to see if the tearing can be eliminated, i would appreciate it. I have attached the sketch, guibuilder project file, and libraries (GUISlice, TFT_eSPI, TimerObject). If the tearing now seems normal behaviour, then I'm happy to keep it as is, it's not noticeable unless you look for it. Thanks! RedrawStrobeIssue295.zip

[Pconti31]

@ASMotionLab @ImpulseAdventure Hi, I don't have anything to do with the API but I did write and do support the Builder. So I thought I would answer why the Builder doesn't have FillEnable setting. The answer is simply that it does but I thought it would confuse people so I just word it as "Transparent?= false" as default. If you set "Transparent?= true" it creates the gslc_ElemSetFillEn(&m_gui,imageElement,false) API call. Otherwise no call is made since the API default is Fill is enabled. There was a bug in earlier versions that wouldn't set this correctly. Paul--

[loopyengineeringco]

Thank you @Pconti31 for explaining, it makes perfect sense.

[ImpulseAdventure]

@ASMotionLab -- thanks again for the detailed analysis!

When you set E_ELEM_IMAGE34 and E_ELEM_IMAGE_35 to use FillEn(false), you should not see any white strobing effect. ie.:

You mentioned that you are still observing tearing -- was this referring to the black redraw before the image button is redrawn? If so, this briefly appears because: a) the current image draw routines support transparency AND b) when we hide or update an element, we need to redraw the background before drawing the [transparent] image since it is difficult to determine a priori what will show through (assumes we don't use more advanced techniques described below)

By utilizing a read/modify/write methodology (only supported by a subset of [readable] displays / drivers) or an offscreen bitmap, it may be possible to enhance the redraw routines to eliminate such "overdraw", but unfortunately I haven't tried embarking on this as these features are not widely available.

Perhaps I could add an API that adds an image attribute that indicates whether transparency is required or not. This would enable one to determine when the underlying images / background are fully obscured and hence we can optimize the redraw. This might work for your case since I don't believe your particular icons relied on transparency.

Let me look into this to see if this can be done without too much work. Please note that I am quite busy at the moment and may not have an opportunity to try this out for a bit.

thanks!

[Pconti31]

@ASMotionLab @ImpulseAdventure I wonder if a better and more consistent solution than a new API would be to simply add a new feature say transparent fill color for images. Currently setting a Fill Enabled to false means the UI element is transparent and you deal with as such. But this doesn't cover this case where he wants the image to be non-transparent but still don't refresh background. I would think that first checking the fill color for say your current transparent "pink" could than indicate to your API to optimize by not refreshing background for this UI element. The Builder could even add a "Transparent" Color to the possible fill color selections. Just a thought. Paul--