That's really nice, thank you!

From my reading, to be maximally cross-platform compatible, it sounds like we should send an artificial Background event just before Suspend on Android, and an artificial Foreground just after Resumed (on all platforms, actually)?

Hmm, actually it sounds like applicationDidEnterBackground: matches the semantics of the Suspend event on Android better than applicationWillResignActive:?

@rib: Is there an event on Android that requests the application to pause things (e.g. pause the game) and go into a low-power state, without necessarily suspending everything?

From my reading, to be maximally cross-platform compatible, it sounds like we should send an artificial Background event just before Suspend on Android, and an artificial Foreground just after Resumed (on all platforms, actually)?

Is it OK if I add those artificial events on other platforms, with a TODO to move them to the correct events on Android for now?

Web should probably use these for the pagehide and pageshow events, currently it uses Occluded instead.
Should we also emit Occluded with Foreground and Background?
Should this be folded into the new WindowState (#2929)?

If the whole intent is to stop rendering based on foreground/background Occluded sounds like a better choice.

My suggestion was to use both, Occluded and Foreground/Background.

Maybe I'm misunderstanding Foreground/Background, my assumption was that if something is in the background it's not visible, ergo occluded.

I mean, what's the reason to add them, if Occluded could indicate Foreground/Background?

I mean, what's the reason to add them, if Occluded could indicate Foreground/Background?

For the same reason this PR adds Foreground/Background: it's interesting to some applications. Occluded can mean different things, not only that it's Foreground/Background.

@daxpedda it's simply a hint saying that you could stop rendering.

I mean, what's the reason to add them, if Occluded could indicate Foreground/Background?

@daxpedda it's simply a hint saying that you could stop rendering.

I agree, that's why I am proposing to send both, because Occluded should not indicate anything else then to stop rendering.

@daxpedda I'm just arguing against adding special events for ios where we already can use existing Occluded event.

Occluded is a WindowEvent, while Foreground/Background are application events. When dealing with them, you're not bound to any specific window, and putting them as WindowEventwould (in my opinion) break some of their meaning.

That said, that limit on iOS at least is quite blurry as it's not possible to have more than one window, so it may be ok to mix those there...

Occluded is a WindowEvent, while Foreground/Background are application events. When dealing with them, you're not bound to any specific window, and putting them as WindowEventwould (in my opinion) break some of their meaning.

That said, that limit on iOS at least is quite blurry as it's not possible to have more than one window, so it may be ok to mix those there...

I mean, as long as window is not destroyed it's fine to use Occluded for that. You can even send them for each window in a loop if multiple windows will be a thing. The good thing about this event is that you'll get expected handling on other platforms, because they usually stop rendering when occluded happens.

Moved to WindowEvent::Occluded