Filled Path degrades the Performance

asked Jun 11 in Platform Packages by Preethi S

We are currently using 300 * 300 Filled Path for RPM and the viewport is 800 * 480. Whenever there is a rapid change in the updation of Filled Path there is a performance drop visible stuttering. Similary we tried using Gauge Widget for the same , there also drop in performance is seen .

Anyway to improve this performance drop?

Anyother alternative way instead of FilledPath/Gauge (like Masking)?

Any possibility of smooth transition(animation) if there is jump in input value to Filled Path. i.e. how the animation can be handled for smooth transition within filled path?


1 Answer

0 votes
answered Jun 11 by Paul Banach


have you tried to disable the antialiasing? Also interesting to understand the problem, which target are you using? 

Generally, vector graphic is rasterized by using the CPU. The performance is limited by the used HW. Also important, if you are using an OpenGL or WebGL platform package, you should take in account that on these targets the rasterized vector images need to be copied to texture memory. This may impact the performance significatly if the underlying OpenGL/WebGL API is not well optimized.

From your question I understood you want to display a rotating pointer (needle). Have you tried to achieve the same by using the Warp Image view?

Best regards

Paul Banach

commented Jun 12 by Preethi S
Hi Paul,

We are currently using NXP IMXRT1050 with Embedded Wizard 9.0.
Viewport is of 800 * 480.
The usecase is not related to gauge with rotating pointer. We are trying to use Arc Path + Filled Path of dimensions 300 * 300 and we are filling it with a gradient .

We analysed the performance metrics from our side. Frame time for single update i.e. ``update (viewport,rootobject)`` in main.cpp takes above 80 ms whenever there is a frequent/rapid update in the filled path. 80 ms frame time for single update is too high.

We also tried both with/without gradient , the result is same.

As suggested we tried removing antialiasing , then also there is the same drop in performance. And removing antialiasing will have visual artifacts too.


Best Regards,

Preethi S

Robert Bosch - India
commented Jun 12 by Paul Banach

Hello Preethi,

IMXRT1050 does not contain OpenGL core. As such the hint in my preceding answer is obsolete. The target is powerful (~600 MHz) and 80 ms time to draw a 300x300 pixel large filled path content seems to be much.

What can we do?

One cause for the problem could be an excessively high number of path segments. The more segments, the more iterations are needed during the rasterization to find out whether a pixel does lie inside/outside of the path. With the Arc Path view you can configure the number of segments. Have you tried to configure this value with e.g. 50?

Other reason for the problem can be related to other screen contents lying e.g. behind the Filled Path view. Every time the Filled Path view is invalidated, all the views intersecting its area need also an update. Can you try to simplify the application, so that it consists of the Filled Path view only? Now no other views should interfere with the update. Is it better?

From your answer I understood, that you are using a color gradient. Gradients in fact will reduce the performance (especially if theye are horizontal on a system with screen rotation = 0/180 degree or vertical on system with screen rotation = 90/270 degree). You have disabled the gradient. Can you verify once more that the properties ColorTL, ColorBL, ColorTR and ColorBR of the Filled Path view all are deinitialized so no gradient is used?

So far few ideas, what you can try out.

Since Bosch booked support contingent, we can also evaluate your project more in detail. May be we can detect the cause of the problem. You can send the project (together with all needed images) to us by using the e-mail

Best regards

Paul Banach

commented Jun 13 by Preethi S
Hi Paul,

Thanks for the quick suggestions, we are working on the same.

1 . Analyzed the number of edges - maximum tried with 25 which gives smooth arc, with that there is no improvement in performance. Trying to reduce more edges than 25 distorts the shape of arc path

2. Invalidation - Filled Path is placed on top of background rectangle which is of full resolution and it is surrounded with other elements like text and bitmaps whose bounds intersects with gauge. Removing all these improves the performance to some extent. i.e. if the path is partially filled there is improvement in performance , but if it is filled completely performance again drops even though removing all intersecting elements.

By the way, we need all those intersecting elements. Removing it doesn't make sense in our case

3. Filled path gradient - removing the gradient doesn't improve the performance.

I have few more queries,

1. Moving to Embedded Wizard Version 9.2 will improve the performance , since it has new graphic stack (pxp accelerator)?

2.As of now , we are using RGBA8888 color format, in anyway RGB565 improve the performance ? If so then RGB565 supports blending of non alpha pixels of bitmap?

We will come back to you via mail/skype somewhere on start of next week for more suggestions and discussions on the same

Best Regards,

Preethi S

Robert Bosch - India
commented Jun 13 by Paul Banach
Hello Preethi,

hmmm ... I don't expect any improvement with PXP. The path drawing operations are perfomed by the CPU so we will not benefit from PXP. Switching to RGB565 could eventually improve the performance. Especially on systems with low memory bus throughput. Using alpha blending with RGB565 is possible. RGB565 is used for the framebuffer only. All other contents like icons, images, etc. can be managed as RGBA8888 bitmaps with their associated opacity information.

Till now I have not really understood what happens in your system and causes the delays. I have thus following questions:

1. Are you using the i.MX RT1050 Evaluation Kit (MIMXRT1050-EVKB) or are you working with your own designed hardware? Maybe there is an issue with RAM performance, data cache, etc.?

2. Have you modified the files provided with Embedded or with the build environment?

3. Are you using multithreading so that several threads do access Embedded Wizard GUI application? This should be avoided in any case.

To continue with the investigation it would be useful for me to see your project. Can you isolate the problem in a small Embedded Wizard project and provide it to me?

Best regards

Paul Banach

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint