Problems with Viewport

[thor171]

Hi!

First of all, it's great to have a forum for discussions about problems how to use this lib in the right way.

In my project, I apply a viewport on a TFT_eSPI object called tft.
What I do is, before I apply the viewport, I push a background image to the tft, which works. Then I apply the viewport and try to push a sprite to tft. It kind of works, but with glitches. The lcd has a resolution of 240x240, the sprite also has a resolution of 240x240, it's basically a copy of the background image. The sprite is only applied to the viewport, but in the top of the viewport is a black bar I can't explain why it is there.
If I apply fillScreen(TFT_WHITE) to the tft object, it works perfectly fine, only the viewport is white without any black bars.
Does this happen because the sprite is bigger than the viewport?

[Bodmer]

This may be a bug in the library or sketch. Please post a complete example sketch that demonstrates the problem.

[thor171]

Well, I try another approach using sprites. I noticed I could do what I want using sprites only and save some memory.
But with this solution, I ran into another problem. The code is attached.
It's basically your AnimatedDial example with some modifications. I can't read from the LCD's memory, so I create an array of eSprites which initially contains the area of the background I need to modify.
Two of those copies are used as a framebuffer. One is for reading the background + the rotated needle, while the other one is for plotting the new position of the needle for the next transfer. If the transfer is finished, the buffers are switched.
Before plotting the needle to the framebuffer, I push one of the three sprites which is after initialization never touched again, to the actual buffer in order to get a clean background without the old needle.

But it's very strange, for some reason, if one of the three sprites is modified, they are all modified. This seems to be a bug in your library. It seems like they're pointing to the same data, but they intended to be copies which should contain different data.
In order to demonstrate this, I changed the sendSprite() method and push only the unmodified to the tft. So the needle should be never plotted on the lcd's screen, but it is.
DZM.zip

[Bodmer]

I do not have the time to look in detail at users own projects. A quick look at this sketch line makes me think all the instance array is initialised to the same value (object reference), so then only one sprite will be created, not 3:

TFT_eSprite needleRect[3] = TFT_eSprite(&tft);

The other observation is that you are trying to create 3 very large sprites, this will not be possible unless your board has PSRAM fitted.

[thor171]

Ok, but in your AnimatedDial example you intialise two sprites referencing the only tft object, too. Why does this work?
If I create different sprites referencing to the same tft object, this shouldn't be a problem, because sprites are intended to be displayed on the same screen, I assume.

Memory shouldn't be a problem since I'm using an ESP32-Wrover which has 8MB PSRAM.

The references to the sprite objects seems to be different, I printed them:

18:50:00.366 -> Object 0 = 3ffc03a0
18:50:00.366 -> Object 1 = 3ffc0234
18:50:00.366 -> Object 2 = 3ffc050c

[Bodmer]

I think you have printed out the addresses of the array elements which are bound to be different.

The problem is that an array of different instances cannot be created when the constructor is parameterised. So the simple solution is to change your sketch so you have explicitly declared separate instances e.g.:

TFT_eSPI tft = TFT_eSPI();

TFT_eSprite spr1 = TFT_eSprite(&tft);
TFT_eSprite spr2 = TFT_eSprite(&tft);
TFT_eSprite spr3 = TFT_eSprite(&tft);

TFT_eSprite needle = TFT_eSprite(&tft);

[thor171]

Actually, this is what I tried meanwhile, but without success. The behaviour is still the same.

[Bodmer]

I can't see a reason why it fails and I see in one of my examples I used and array of instances and it worked. I confirm the results, out of curiosity I created a simplified version and it works OK without the double buffering and dual processor:
simplifiedDMZ.zip

[Bodmer]

It runs OK on my setup with PSRAM disabled. Maybe 4x faster as PSRAM to PSRAM copies are quite slow for large memory blocks.

[Bodmer]

Had another look at this and adapted to only update the screen in the needle zone. Needle angle increments must not be too big for this to work (i.e. not leave bits of needle image on screen) as it does not use the "old" angle zone. Performance then is much better, about 60fps with PSRAM and about 160fps when not using PSRAM for the sprites. This does not implement double buffering and one of the sprites created is not used, so that code can be deleted. A nice example for a dial.

myDZM_array2.zip

[thor171]

Wow, that's fast! Even without using the second core.
I think this whole problem is indeed memory size related. If you change line 53 in drawZeiger.ino like this:

needle.getRotatedBounds(45, &min_x, &min_y, &max_x, &max_y);

Replacing the 30 with 45, the problem can be reproduced even with your example. (PSRAM disabled)
I tested some debug code and it seems neither of my ESP32 modules do have PSRAM, even the WROOM. The debug code should print the size, if available, but it says init failed, so I think they don't have one.

If you want to add this code as an example, I am going to change the variable and function names so everything is in english. Also I would change the dial face a bit, because this might infringe some copyright laws^^'

Out of curiosity, where did you buy your ESP32 with PSRAM?

Thank you for your time investigating this. :-)

EDIT: I attached an example omitting the unused stuff.
Animated_dial_2.zip

[Bodmer]

My board is a TTGO T8 with 4Mb PSRAM. Mine is v1.1, it is not the best board I have as the little on/off switch broke the first day of using and, with Windows 10, I usually need to press the BOOT button for it to program due to the boot timeout being too short.

I updated the sketch to use a viewport in the destination sprite, this is set to the rotated needle bounding box and gives a performance boost to circa 100fps for PSRAM and 200fps for normal RAM. Due to PSRAM caching the speed varies significantly depending on the shape of the area to update, so a timed loop is required to keep the needle draw speed down. Here is my latest version.
myDZM_array3.zip

It has been an interesting distraction. Even with PSRAM the sprites were being incorrectly overwritten when the dual core is used, I think this may be down to limitations in the RTOS and the caching.

As far as I can see there are no issues with the viewport feature or sprite handling in the library, so I assume that problem you had was related to the same memory over-write issue that has now been solved.

[thor171]

Yes, your're right. The problem is solved. Thank you 👍

EDIT: I tested your viewport example, works great, except for a little glitch, on the screen are some remains of the needle drawn before in the old position. I think this happens, because the viewport for e.g. 89 degree doesn't contain the whole area occupied by the needle at e.g. 88 degree.
But at this point, I will figure it out by myself :-)

[Bodmer]

I expect you have realised that the needle rotated bounds should be calculated with the "old" angle, not the new one so the last needle image is over-written. Then the needle increment will not need to be small. The viewport bounds will then need to be updated for the new angle before drawing the new needle position.

[thor171]

Indeed I did. :-D
That's exactly what I changed. I was also thinking, the memory consumption could be reduced by dynamically create and delete the sprite in which the needle is plotted, by calculating the needed size by bounds.
I think I will implement this, even if the ESP32 has plenty of RAM available for what else it has to do.

[Bodmer]

If you have PSRAM this would be OK, but without it you can end up fragmenting the heap and then a sprite creation will fail at some point. One way is to create a square sprite with sides equal to the needle height plus margin. You must then move the pivot point for the needle rendering.

[thor171]

Ah, I see. I was wondering if fragmentation could be a problem, because I heard about that before.
Your suggested solution would also save a lot of memory, I think I am going to implement this, thanks for the hint.