High CPU usage

[dionyziz]

The rendering main loop keeps being called even when it's unnecessary. Make it run only when needed.

[DmitryMyadzelets]

Using shadows and gradient colors with canvas is very time consuming. I've done a test where replaced a gradient color of states with a solid color, and remove shadow of states. Now, the rendering time is 25 times lower then before (30ms vs 750ms with my setup).

Can the gradient colors and shadows be replaced with solid colors, and other ways to highlight the elements?

Surely, that doesn't change the high CPU load but it's definitely an improvement of performance.

[dionyziz]

Thanks for your suggestion. Maybe we can add this as a setting. Would you like to work on a PR for this?

On Sat, Oct 25, 2014 at 6:21 PM, Dmitry Myadzelets <notifications@github.com

wrote:

Using shadows and gradient colors with canvas is very time consuming. I've done a test where replaced a gradient color of states with a solid color, and remove shadow of states. Now, the rendering time is 25 times lower then before (30ms vs 750ms with my setup).

Can the gradient colors and shadows be replaced with solid colors, and other ways to highlight the elements?

Surely, that doesn't change the high CPU load but it's definitely an improvement of performance.

— Reply to this email directly or view it on GitHub https://github.com/dionyziz/Automata/issues/25#issuecomment-60488053.

[DmitryMyadzelets]

I've made a PR #44 w.r.t. issue #22. It's also related to this issue #25, but this one must be fixed by removing the rendering in the loop, i.e. rendering should be invoked when it's necessary.

After inspection of the code I see three contexts the rendering must done:

1. The editor window resize (currently this code is isolated and has no access to the editor).
2. Changes which change the model (automaton).
3. Changes which don't change the model, but change the view. The 2nd and 3d can be done simply by invoking render() in the handleMouseMotion function, since it is the central one in this code, and called for the all events. I can make a PR for that, if necessary.

[dionyziz]

This sounds about right, I agree with your approach. Please file a PR and I'll be very happy to review you.

[DmitryMyadzelets]

I'm rethinking the logic of PR. In fact, the rendering process can be viewed as a state machine. We have set of 3 events:

1. Request (for rendering)
2. Rendering combined with setting timeout by requestAnimFrame
3. Tout (after requestAnimFrame). The logic can be depicted with a classical automaton as follows: Equally, with a Mealy automaton:

In other words, it request one 3-state variable or combination of two variables for correct behavior. The current PR is "cheating" since it does rendering after the timeout, not before. After timeout request sets to false, i.e if any request made during timeout will be not noticed.

What do you think? I'd remake the logic

[DmitryMyadzelets]

Meanwhile, I've fixed the PR according to your comments. It just works without the above considerations.

[DmitryMyadzelets]

Shouldn't it be closed after the last update?

[dionyziz]

Yes, thank you. I'm closing this issue as it is now fixed.