Touchgfx 4.19.1 performance are really poor compare to 4.18.1

[SBACO]

Hello,

I just try the latest 4.19.1 (coming from 4.18.1) and the performance of this new release is just horrible in my project. Regarding the release note, I do not see anything that can really explain a slowest behaviour as it seems most of the upgrade are regarding the designer for font converter. So except if not fonts are handle really differently in the touchgfx framework, I really have no idea of what happens. I will roll back to 4.18.1. One more thing, but there is a crash now when removing all pages from a swiper, this was possible in older version (I am removing all pages to reorganize them depending of customer wishing).

If someone has an idea or share the same experience, will be really appreciated to share.

[Yoann KLEIN]

Hello @SBACO​ ,

Did you try to use the latest version of TouchGFXDesigner, 4.20.0, that we just released a few days ago ?

If not, could you please try it, and let me know if works better or if you still have the same issues.

Thanks,

/Yoann

[SBACO]

I just try the 4.20.0 in case there is any improvement here, but it does not seems so. Vertical animation are really more poor. Like "homemade" extension for bottom to top that move the whole screen to the top.

4.18.1 was a lot better doing this operation. I have not done yet a full testing of my app running 4.20.0, but I can confirm this is less efficient.

[SBACO]

and thanks for your reply !

[SBACO]

I am adding one thing here, but the generated fonts are differents between 4.18.1 and 4.20.0. So all people storing fonts in external flash and do not expect to update it will be stucked again (this already appears somewhere between 4.13 and 4.18 as I remember, i wrote a ticket for that a few month ago, no solution was available).

[Flemming Gram CHRISTENSEN]

Hi SBACO

I will get in touch with you to understand the problem and have it fixed for future release. It is not the intention that performance should be lower.

Best Regards

[Dejan Nedeljkovic]

Hi @Flemming Gram CHRISTENSEN​ 

I could also observe the poor performance of 4.20. I just updated from 4.17 to 4.20.

Loading and closing widgets have really strange behaviour. It looks like it closes half of the widget (some pixels) and the other half is still there. It takes some second to completely update the screen.

I could observe the same behaviour with flashing buttons (just color changes) in handleTickEvent. This takes place very delayed and this delay varies.

I also observed the same behaviour as with the widgets when I hide the button and show a new one in the same position.

I've noticed that drawCacheEnabled in Application.hpp does no more exist.

I had in FrontendApplication.hpp the following code:

virtual void draw(Rect& rect)
    {
        if (drawCacheEnabled)
        {
            // Invalidate entire screen instead of requested rect.
            Rect r(0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT);
            Application::draw(r);
        }
        else
        {
            // Use original rect if we are *actually* drawing and not just invalidating.
            Application::draw(rect);
        }
    }

and now I had to change that to:

virtual void draw(Rect& rect)
    {
        // Invalidate entire screen instead of requested rect.
    	Rect r(0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT);
    	Application::draw(r);
    }

I may downgrade to 4.18.1 if there is no solution to make the GUI smoother.

Have I possibly forgotten to make a setting so that the new TouchGFX version runs more smoothly?

Regards

Dejan

[Flemming Gram CHRISTENSEN]

Hi Dejan.

Thank you for posting. I think your problem is different. Your old code caused the whole screen to be invalidated whenever the application invalidated any rect. (could you explain the use case for that? - just curious).

In TouchGFX 4.18.1 Application::draw() had two purposes. One is to draw, the other is to invalidate areas. This was controlled by the drawCacheEnabled. We decided to clean this up in 4.19.

The drawing part is now the sole purpose of Application::draw(), so your code now causes the whole screen to be redrawn when a smaller part was supposed to be redrawn. So the screen can be drawn many times. So you should not change the code in draw().

To do your invalidation trick, one way is to override

virtual void drawCachedAreas();

For example as: (not tested)

virtual void drawCachedAreas()

{

  if (!redraw.isEmpty() || !cachedDirtyAreas.isEmpty()) // something is invalidated

{

// make sure everything is invalidated

invalidate();

}

Application::drawCachedAreas();

}

I believe this has the same outcome as your previous code. If anything is invalidated, invalidate the whole screen.

Try that.

NOTE to readers: This is not required in normal applications. Special need.

Regards

[Dejan Nedeljkovic]

Hi @Flemming Gram CHRISTENSEN​ 

The call to draw() was a leftover from earlier. I had to mirror the image (pixel by pixel) because the screen was upside down. But this changed now, so the image mirroring does no more take place.

If I no longer call the draw function, the whole GUI falters.

With the new drawCachedAreas() function, the GUI reacts much faster. Thanks for that.

You are writing that this call is not required in normal applications. But I don't understand why the GUI stalls without this call.

Regards

Dejan