Focused text entry consumes 40%-80% of CPU in my app

[ababo]

Describe the bug:

I have several forms where text entries can take and lose focus. I noticed that when entry is focused (even without entering any text) the CPU consumption seriously increases.

Screenshots

To Reproduce:

Use any app that contains text entries.

Reproducing conditions:

Platform: OS X 11.1
Go version: go1.15.7 darwin/amd64
Fyne version: v2.0.0

Note: This problem is not reproduced with Fyne v1.4.1.

[Jacalz]

Can you please fill out that issue template when opening bug reports? I see that you have used it, but then removed all of the template. Please just use the template which contains the necessary information to diagnose the issues. Thanks for understanding 🙂

[ababo]

@Jacalz updated

[Jacalz]

Thanks 🙂

[bebo-dot-dev]

I see this issue on Linux Mint x64 with fyne v2.0.3. CPU usage seems to be around 25% here and the application has to have focus / be topmost for CPU usage to spike.

[andydotxyz]

Are you also using fyne_demo when you see the problem @bebo-dot-dev ?

[bebo-dot-dev]

Hi @andydotxyz I wasn't using the fyne_demo when I saw this, I was playing with my little proof of concept application

..but now that you mentioned it, yes I can see it with the fyne_demo application too and CPU usage does seem to be ~40% with fyne_demo

[andydotxyz]

Looking into this further I think the issue is that the cursor pulses through every possible frame, so the entire UI is refreshing at 60 FPS. Because we're doing Go->C->OpenGL this is expensive even though we are not actually rendering any new textures.
There are probably 3 possible approaches:

• minimise the cursor pulse (i.e. add pause between a faster fade in and then fade out, so we refresh 1/3 the time)
• implement partial refresh so that we can move to draw only the areas that changed (allow partial texture refresh of CanvasObject #428)
• Find optimisations in our draw pipeline for the situation where we are not actually refreshing much...

I don't think any of these are simple unfortunately so the short term solution may be #1813 ?

[bebo-dot-dev]

Thanks for taking a closer look. I've not profiled power usage on a mobile device but this could make using a fyne app on mobile unfeasible.

Either the first option of reducing cursor pulse or #1813 could be decent short term solutions.

[andydotxyz]

Interestingly it seems to be less of a problem on mobile because, in general, there are fewer things on screen.
The CPU relates to the number of things visible behind the Entry rather than the CPU usage of pulsing itself.

That said it does need to be sorted, though not sure I would switch off animations by default until we know that they are prohibitive.

[dweymouth]

Is there any reason not to disable cursor animations on desktop? As far as I'm aware, on pretty much all desktop OSes and toolkits, the cursor just blinks, it doesn't fade in and out. If the CPU load is already less of an issue on mobile, leaving the fading animation on mobile and removing it on desktop would both mitigate the performance issue and make Fyne match desktop conventions more closely.

[andydotxyz]

Is there any reason not to disable cursor animations on desktop? As far as I'm aware, on pretty much all desktop OSes and toolkits, the cursor just blinks, it doesn't fade in and out. If the CPU load is already less of an issue on mobile, leaving the fading animation on mobile and removing it on desktop would both mitigate the performance issue and make Fyne match desktop conventions more closely.

I don't think they just blink on/off. At least not the more polished UIs. However we could reduce CPU usage through making it a short transition.
That said the latest develop should be magnitudes better as the rectangle is not CPU rendered any more.

[andydotxyz]

This was resolved already