Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom invalidation/redraw area for touch events? #274

Closed
loopyengineeringco opened this issue Sep 28, 2020 · 15 comments
Closed

Custom invalidation/redraw area for touch events? #274

loopyengineeringco opened this issue Sep 28, 2020 · 15 comments
Assignees
Labels
enhancement waiting confirm Believed to be fixed / OK. Waiting on confirmation.

Comments

@loopyengineeringco
Copy link

Hi Calvin,

ESP32/ILI9341/TFT_eSPI

I've managed to create a nice high resolution background image and load it from flash (GUIslice doesn't allow gslc_GetImageFromProg by default, only lslc_GetImageFromFile and gslc_GetImageFromSD.)

1601311930865 (0-00-00-05)

2 things related:

Request #1 - it would be cool for GUI builder to allow loading background image from flash - gslc_GetImageFromProg.

Request #2 is the main issue. As the image is large, it's quite slow to load.
This is obviously a hardware limitation, understandable and fine for initial boot up, but after touching a button it reloads the whole image as opposed to just the portion that's changed.
Is it possible to customise the invalidation/redraw area for each touch event?
So I guess to manually trigger a redraw of a specific area from the touch callback events of each button?

For example here: I'd like only digit #1 to refresh when I hit the left plus or minus. Just like the toggle button only refreshes itself and not the whole background.

1601311930865

Is this possible?

Thank you!

@Pconti31
Copy link
Contributor

Pconti31 commented Sep 28, 2020

@ASMotionLab Requests for the builder should go to the Builder issues . Nevertheless, I'll add your request to my list of possible enhancements to the Builder.
Can't say what the chances of supporting item 2 by Calvin but Tony Pitman and I have an outstanding pull request for a remarkable speed up of loading images from memory for the TFT_eSPI once that goes in it may help you.

I do notice though your image appears to be a single color with buttons so the question is why are you loading single bmp? Even if you need an image for the buttons you can create 6 single image buttons to avoid the refresh. Now its quite possible my monitor doesn't do justice to your BMP if so fell free to discard my advice.
Paul--

@loopyengineeringco
Copy link
Author

Thank you @Pconti31 I should have created 2 separate requests but I thought it might make sense if they were together.

The image background has nice 3d ish looking gradients, the 'panels' are semi transparent and the text is nicely antialiased, it definitely looks much nicer in person - I'm not sure it's worth the horrible performance at the moment though!

The faster image loading sounds amazing, I will look forward to that!

If I sliced the background image into tiles and had them as image objects instead of one background image, would that stop the entire thing refreshing? (I suppose I will try this next)

It would still be super if there was a way of forcing only a region to redraw though. I can see some stuff in the source files but I wish I understood c a bit better!

@Pconti31
Copy link
Contributor

Pconti31 commented Sep 29, 2020

@ASMotionLab Calvin does optimize by regions but the region is the largest block. In this case your BMP. Now I understand your request but most supported systems don't have enough memory or speed to do a bit by bit image compare using a double buffer which IMHO your request would require. Still that's Calvin's call not mine.
If you continue to use the BMP breaking the buttons up into titles likely won't help you since the BMP image will still be the largest block. If you want to try the faster image load before Calvin completes his inspection of our Pull let me know and I'll post the module.
Paul--

@ImpulseAdventure
Copy link
Owner

Hi guys --

@ASMotionLab -- would it be possible to package up your example (including the image) for me to examine?

As Paul points out, the scope of the redraw is generally optimized to the elements that encroach upon the maximum region of change. In this case, however, the button presses should not normally cause a wider ripple effect (eg. page redraw).

That said, there are some scenarios that can trigger a larger scale (eg. page) redraw: eg. when a transparent element needs to be redrawn, it is possible that a different portion of the background could be revealed, necessitating a deeper redraw.

How are your buttons and digits styled? Are they transparent (with "Fill Enable" = false)? If so, can you try changing Fill Enable to true and then setting the fill color to match the flat background color in those regions?

If I can take a look at the project / sketch, I might be able to identify some alternate options. It is also possible that the bitmap redraw is not respecting the boundaries of the invalidation region, so I can take a look at that too.

thx

@ImpulseAdventure
Copy link
Owner

BTW - this discussion reminded me that we had an open PR for the TFT_eSPI pushImage() integration in #250 . I have merged that request now, so it should increase the image rendering performance. Nonetheless, I’d like to see if the button/text transparency setting may make a difference.

@loopyengineeringco
Copy link
Author

loopyengineeringco commented Sep 29, 2020

Hi guys

@Pconti31 I think I misunderstood what you said before: the buttons are actually GUIslice buttons and aren't part of the bg image.

@ImpulseAdventure this is indeed what was happening: I found that if I enable fill on the number elements gslc_ElemSetFillEn(&m_gui,pElemRef,true);, it works as expected - redrawing only the number field.
But when gslc_ElemSetFillEn(&m_gui,pElemRef,false); it redraws the entire background.

Fill_True

For me this is workable - I will set the text background to a colour that's close to the image background and it'll be fine, but it would be cool to use the 'transparency' and it to only redraw the boundary of the text field. In other use cases the background might be busy.
This is what happens for the toggle button, but not for fonts. And it's less computation than the toggle button - it's a rectangle and it already knows the field's X,Y,W,H.

Or if we could specify a manual area for redrawing, would also be super great 👍

Image BG redraw.zip

@mcufriend
Copy link

mcufriend commented Oct 2, 2020

Use buttons to control the display of pictures,stm32f103rbt6 tft_espi guislice sd card jpeg picture 320x480

https://youtu.be/xSoc5ovAdlY

@ImpulseAdventure
Copy link
Owner

@ASMotionLab -- good to see that disabling transparency works as expected.

With the updated TFT_eSPI pushImage() update to GUIslice, the redraw is pretty quick now, but it still redraws more than is necessary. I looked into this further and discovered that the reason is that TFT_eSPI wasn't masking the bitmap redraw region via setAddrWindow() as I had originally incorrectly assumed.

I don't believe TFT_eSPI currently supports a masked / clipped bitmap redraw functionality (e.g. in pushImage), though I have reached out to Bodmer just in case there is another option (aside from sprites).

Out of interest, I added an enhancement locally to TFT_eSPI to introduce the ability to clip the bitmap images to a region. The result is a very fast and localized redraw, as originally intended. So the good news is that I might be able to offer an enhanced solution that provides an optimized redraw with an arbitrary background.

@mcufriend -- when you are changing the image after pressing your "Next" button, the entire image needs redrawing. The full page/image redraw speed in GUIslice should be about the same as what you see in TFT_eSPI directly. Did it appear that something might not be functioning correctly?

thanks!

@loopyengineeringco
Copy link
Author

@ImpulseAdventure this sounds very exciting! Are you hoping that Bodmer will implement your enhancement? This would be great.
Alternatively, I suppose this enhancement could stay local in the GUIslice domain as a custom optimisation perhaps enablable via the setup files. But new TFT_eSPI releases could break it I guess.

This is very promising, thank you for your hard work in making this library better and better! One day it will be better than QT Creator :-)

ImpulseAdventure added a commit that referenced this issue Oct 3, 2020
- Requires the inclusion of https://github.com/ImpulseAdventure/TFT_eSPI/tree/add_setClipRect
- Add #define DRV_DISP_TFT_ESPI_HAS_CLIPRECT in user config
@ImpulseAdventure
Copy link
Owner

Hi @ASMotionLab — I have completed a pull request for TFT_eSPI with the added functionality in case Bodmer might be interested in accepting it. You will find my branch here:
https://github.com/ImpulseAdventure/TFT_eSPI/tree/add_setClipRect

I have also updated GUIslice here to use the new functionality in this branch:
https://github.com/ImpulseAdventure/GUIslice/tree/WIP274-TFT_eSPI-clip

If you would like to give it a try, download and install the above two branches and then add the following to your GUIslice user config file:
#define DRV_DISP_TFT_ESPI_HAS_CLIPRECT

Thanks

@loopyengineeringco
Copy link
Author

Hi guys,

I've suddenly lost my spare time to try out the new commit fully, but tried the new pushImage() update and the speed up is incredible!

So much so that I had to make this comparison gif just because it was hard to believe.
pushImage old vs new

It went from 766ms/frame (ish) to 49ms, around a 15x improvement. Incredible!
(I have a button redraw issue but this should be fixed with the clipping regions update I believe! Only started happening when I removed the corner radius).

I'll test out the clipping regions soon too, but thank you already for this massive improvement!

ImpulseAdventure added a commit that referenced this issue Oct 8, 2020
- Provides greatly enhanced redraw performance for #274
@ImpulseAdventure
Copy link
Owner

Just a quick update to say that Bodmer will be integrating the clipping functionality (it uses a new API: setViewport). This change should make the updates much faster and also eliminate the additional redraw issue you noted).

When he has completed his testing, I will merge the update into GUIslice. To take advantage of this feature, users will need to update TFT_eSPI to version 2.3.0 or above.

@loopyengineeringco
Copy link
Author

Thats great news, thank you for making this happen. Game changer for good looking GUIs!
Will keep an eye out for 2.3.0 TFT_eSPI.

@ImpulseAdventure
Copy link
Owner

Some good news -- Bodmer has now integrated the feature into TFT_eSPI v2.3.2!

If you want to try it out:

The latest update in GUIslice should auto-detect the presence of the new TFT_eSPI viewport feature and activate it in GUIslice for redraws. Once you have had an opportunity to try it out, I can merge these changes into the main GUIslice repository. Bodmer's v2.3.2 should become available via the Arduino IDE library manager when he next makes an official release.

thanks!

@ImpulseAdventure ImpulseAdventure added enhancement waiting confirm Believed to be fixed / OK. Waiting on confirmation. labels Oct 14, 2020
@ImpulseAdventure ImpulseAdventure self-assigned this Oct 14, 2020
@ImpulseAdventure
Copy link
Owner

Closing as the feature has now been merged via #281 .

Note that at this time TFT_eSPI doesn't have an official library manager release for v2.3.2, but the updated feature can still be accessed by downloading the latest from the TFT_eSPI repo. No changes to your user configuration are needed to enable the new feature.

@ASMotionLab -- if you later uncover any issues with the new functionality, please feel free to file a new issue.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement waiting confirm Believed to be fixed / OK. Waiting on confirmation.
Projects
None yet
Development

No branches or pull requests

4 participants