High CPU usage about asciimatics

[peterbrittain]

Good question! It's all to do with the screen refresh...

Asciimatics is ultimately designed to create animations and so follows the same principle as video games to redraw the screen many times a second. Even with no changes at all, it will spend CPU time checking the screen needs no refresh.

I could try putting an optimization in there to spot if the screen has changed as updates are made for each frame. That might fix the CPU drain for simple animations like a TUI. Would that be worth investigating?

[chisaipete]

I vote yes! I saw the same issue.

[syntonym]

Yes, I think something in that direction would help dramatically.

I've dived a bit into the code and noticed that even if I comment out the refresh call in the draw_next_frame function here things still get written to the screen. Shouldn't the refresh function be responsible for actually writing stuff to the screen or did I misunderstand something?

Also do effects write all their content into the screen buffer each frame and then the screen checks for each character if it has changed and then writes the changed letters to the screen?

[peterbrittain]

OK - I'll take a look at that optimization soon...

In the meantime, I'm surprised you get any output to the screen if you comment out the call to refresh as that should be the only place that calls the internal _print_at functions which actually update the screen. I would therefore expect the screen just to be cleared with refresh disabled....

[peterbrittain]

A quick play with it shows that it's actually the Effects that are using the CPU, not the drawing to the Screen, so the only way to reduce CPU usage is to stop even attempting to update the Effects. This is a trade-off that isn't going to work for everyone... Some people will just want the original animation speed and others (like you) will want a more CPU-efficient refresh rate.

I've tried to make the UI more responsive whenever there is any input, but to fall back to a configurable idle frame rate with this patch (bc77670). On my system, that reduces the CPU usage on contact_list by ~80% and yet stays just about responsive enough for human input.

Can you try this out and let me know if that does the trick?

[peterbrittain]

After a little more testing of the UI interactions, I wasn't happy with the above patch as it caused problems with Effects that counted refreshes versus ones that used absolute frame numbers.

I've therefore updated the patch with this (6b336fc) which dynamically figures out when we next have to refresh. This currently only affects TUI systems that use Frames (like the contact_list.py sample) as all other Effects demand a refresh for every frame update,

This patch maintains synchronization between Effect types and drops the contact_list sample down to negligible CPU usage when nothing is happening. I therefore think this bug is fixed and will update docs before closing...

Please shout if you think I've missed anything.

[syntonym]

This works great!

I still have a small nitpick: Blinking (used for the cursor in textinput) still needs updates. Is it possible to (optionally) use the terminal blinking (\033[5m)? I know it's not supported on many terminals (and on windows is possible even worse) but it saves a lot when it is available. Maybe configurable with the default on the current rendering?

[syntonym]

I would be very happy if activating terminal blinking does not only insert the blinking escape sequence but also some color fallback when blinking is not supported. That way I can see the cursor even on terminals that do not support blinking, without using too much CPU.

[peterbrittain]

Unfortunately, it's not that simple as the Terminal cursor isn't where you think it is. It will actually be at the last updated character on the screen, which will typically be somewhere near the bottom right of the screen.

You can get some idea of the issues of switching it on by commenting out this line (https://github.com/peterbrittain/asciimatics/blob/master/asciimatics/screen.py#L1724), which hides the terminal cursor, and running the existing samples. While it might work in some very specific cases, it really doesn't work for all. Your proposal would require some very fragile code to detect those precise conditions and temporarily re-enable the cursor. I don't think I have the spare time to get that working perfectly (and it would probably keep breaking as people invent ever more cunning ways to use the package)...

How about an option to use a solid cursor instead of a flashing one instead? That would remove the animation and so also fix any CPU drain. The default would be to animate the cursor for backwards compatibility.

[syntonym]

I meant something different: Some terminals offer the ability to print blinking text (so not just the cursor but text at a specified location, you can try echo -e "\033[5mBlinking\033[0m" if you are on linux). Unfortunately support for that is so rare that it's not worth it. Even when supported it can has quirks, rxvt only blinks text with the default background color.

An (optional) solid cursor (or anything that reduces CPU drain) would be great!

[peterbrittain]

My mistake... I should have looked up the ANSI escape sequence you suggested. That said, you're right that I can't get that reliably on anywhere near all the environments I need to support.

I'll have a look at a solid reverse colour cursor option and then close this out.

[peterbrittain]

Final check-in now uses an inverse cursor if you ask for reduced CPU when constructing a Frame.