High CPU usage when using custom icons on TreeView component

Hi

We found out that when using something else than default icon on tree view it gets huge CPU usage.
Tried different icons but it seems to be problem allways if use something else than “default”.
Now we changed those back to default but would be nice to use own icons.

Br
Tommi Vahtera
THT Control Oy

Hi.

I have the same problem with tree view icons. When I assign another path icon on the icon’s properties of tree view, different from by default, CPU’s load is increased a lot.

Is there anyway to solve that?

Thanks.

Is your tree view’s data polling? If so, turn it off to see if the CPU spike goes away. I think it might be the fact that it is refreshing quickly. We will look into it some more here.

Hi

We are using now static dataset, so I thing it is not polling at all?
But we will change this in near future based on query, but in there also we need polling because we want make dynamic tree view. Of course polling can be slow.

Br
Tommi Vahtera
THT Control Oy

Does it stay at high CPU or is it just a spike?

It stays all time.
I tested this on windows,linux and iMac.
Every machine gets 50% CPU instead normal 3-5%.

I find this problem because I wonder why processor blower was running max all the time.

I thing you should see this easily if you drop Tree view and change dataset icon something else than default.

I just downloaded newest beta, i will test it also.

Yes it occurs in 7.1.7 also. I just made new window, drop treeview and change default icon to some symbol, in vista machine goes 99% cpu, (of course Vista loves CPU:))

Br
Tommi

Here is screen captures before and after.

Br
Tommi




Hi,

The CPU’s load doesn’t change depending the dataset. It is only changing when you decide to change the icons.
In my case, I have a query in an off poll mode, and it’s just executed when I have to refresh the information inside of it. But not often.

Thanks.

Wow this is a weird one. Thanks for reporting it - I’ve made a ticket for it to get investigated further.

This has been fixed for 7.1.8