flutter_embedder_example application manages to fully load one of my CPU cores.
Also after switching desktops it usually looks like this until i resize it or press any button in the gui:

First can be probably fixed by sleeping a bit (can heavily reduce CPU load, but sleep must be balanced to not decrease FPS heavily)
Second can be fixed by rerendering the window every N milliseconds without any conditions (this looks like conditional rerendering or something like that) (basically continuation of first solution).
CPU is a duplicate of issue #58; retitling for the rendering issue.
Also... any plans on packaging (.deb/.rmp/.tar.gz) script support?
Please file a separate report for each bug or feature request.
Regarding rendering issue: it works almost as intended if focus is within a text field.
I haven't experimented with this, but it's likely that we need use glfwSetWindowRefreshCallback to set something that triggers a Flutter redraw.
@chinmaygarde is there any way to request a redraw via the embedding API, other than setting the window size again?
@stuartmorgan I think perhaps sending AppLifecycleState.resumed message on the flutter/lifecycle channel would trigger re-render. See https://github.com/flutter/engine/blob/master/shell/common/engine.cc#L291
It does look that way. However, I'd rather not abuse a message that has a specific meaning that doesn't align with the condition being expressed, as that's fragile. (For instance, that message also attempts to start the animator in the current code; maybe that's a no-op if it's already running, or maybe it has undesirable side-effects. Even if it currently doesn't, there's no guarantee that it won't in the future.)
I am seeing this issue as well and adding a glfwSetWindowRefreshCallback fixes it. I hacked the callback to send a FlutterWindowMetricsEvent with the same size as current and that triggers a re-render.
But I'd be great to have that as part of the embedder API.
If you'd like to send that as a PR I'm fine with that as a workaround until there's something more specific in the engine API.
Most helpful comment
It does look that way. However, I'd rather not abuse a message that has a specific meaning that doesn't align with the condition being expressed, as that's fragile. (For instance, that message also attempts to start the animator in the current code; maybe that's a no-op if it's already running, or maybe it has undesirable side-effects. Even if it currently doesn't, there's no guarantee that it won't in the future.)