Support SDL_ActiveEvent

Support SDL_ActiveEvent

SDL tracks three kinds of application state: SDL_APPACTIVE, SDL_APPINPUTFOCUS,
and SDL_APPMOUSEFOCUS. The first corresponds to whether the window is
minimized, the second to keyboard focus, and the third to whether the mouse is
over the window. For NaCl, I believe the best analogues are
PP_INPUTEVENT_TYPE_MOUSEENTER and PP_INPUTEVENT_TYPE_MOUSELEAVE for
SDL_APPMOUSEFOCUS, keyboard focus for SDL_APPINPUTFOCUS, and page visibility
for SDL_APPACTIVE.

SDL_APPMOUSEFOCUS can be supported easily with SDL_NACL_PushEvent. For the
other two, I believe we need new entry points, and possible even JS postMessage
involvement. Page visibility is exposed in pepper 18 via
pp::Instance::DidChangeView(View) and pp::View::IsPageVisible(), but that's not
on stable yet. Focus should be pp::Instance::DidChangeFocus(bool), but that
appears to be updated only when WebKit-internal focus changes. It doesn't notice
when you switch tabs or windows, unlike DOM focus and blur events. Unclear if
this is intentional or an oversight in the implementation.

The main thing this buys is that SDL calls SDL_ResetKeyboard() when input focus
is lost. This means it, e.g., generates a fake key-up event for Ctrl when
switching tabs with Ctrl-Tab, otherwise the module keeps thinking Ctrl is held
down. Some ports may also useful things with the others, such as pausing when
SDL_APPACTIVE is lost.

Implementation-wise, this is a little invasive as it rewrites the internal
event queue to use SDL_Event as the intermediate structure as that seemed
cleanest.

Landed as https://chromiumcodereview.appspot.com/9963099/

[davidben, 2012-03-27 03:21:20]

This is somewhat invasive, so it may warrant considerable testing before
landing. Shoehorning a non-pp::InputEvent value into SDL_NACL_Event was awkward,
and I think SDL_Event is a cleaner intermediate value anyway. I did a quick test
with scummvm-1.2.1 in naclports and it doesn't seem to break. Also my UQM port,
but it only takes keyboard input, so it's not as good a test.

For my purposes, I'm most interested in the SDL_ResetKeyboard call that comes
with losing SDL_APPINPUTFOCUS, but the rest of SDL_ActiveEvent was easy enough
to add in. (UQM was kind enough to pick Ctrl and Shift as actions...
Ctrl-Shift-Tab is disastrous.)

Feel free to rename the new SDL_NACL_* functions if you have better names...
possibly SDL_NACL_SetHasFocus should be SDL_NACL_DidChangeFocus to match PPAPI.
I named it something else because DidChangeFocus doesn't quite work (see CL
description).

[Evgeniy Stepanov, 2012-03-27 10:37:33]

On 2012/03/27 03:21:20, David Benjamin wrote:
> This is somewhat invasive, so it may warrant considerable testing before
> landing. Shoehorning a non-pp::InputEvent value into SDL_NACL_Event was
awkward,
> and I think SDL_Event is a cleaner intermediate value anyway. I did a quick
test
> with scummvm-1.2.1 in naclports and it doesn't seem to break. Also my UQM
port,
> but it only takes keyboard input, so it's not as good a test.
> 
> For my purposes, I'm most interested in the SDL_ResetKeyboard call that comes
> with losing SDL_APPINPUTFOCUS, but the rest of SDL_ActiveEvent was easy enough
> to add in. (UQM was kind enough to pick Ctrl and Shift as actions...
> Ctrl-Shift-Tab is disastrous.)
> 
> Feel free to rename the new SDL_NACL_* functions if you have better names...
> possibly SDL_NACL_SetHasFocus should be SDL_NACL_DidChangeFocus to match
PPAPI.
> I named it something else because DidChangeFocus doesn't quite work (see CL
> description).

I like this in general. I'll take a closer look in a day or two, and I'll also
test it with Wesnoth.

[Evgeniy Stepanov, 2012-03-30 15:01:28]

On 2012/03/27 10:37:33, Evgeniy Stepanov wrote:
> On 2012/03/27 03:21:20, David Benjamin wrote:
> > This is somewhat invasive, so it may warrant considerable testing before
> > landing. Shoehorning a non-pp::InputEvent value into SDL_NACL_Event was
> awkward,
> > and I think SDL_Event is a cleaner intermediate value anyway. I did a quick
> test
> > with scummvm-1.2.1 in naclports and it doesn't seem to break. Also my UQM
> port,
> > but it only takes keyboard input, so it's not as good a test.
> > 
> > For my purposes, I'm most interested in the SDL_ResetKeyboard call that
comes
> > with losing SDL_APPINPUTFOCUS, but the rest of SDL_ActiveEvent was easy
enough
> > to add in. (UQM was kind enough to pick Ctrl and Shift as actions...
> > Ctrl-Shift-Tab is disastrous.)
> > 
> > Feel free to rename the new SDL_NACL_* functions if you have better names...
> > possibly SDL_NACL_SetHasFocus should be SDL_NACL_DidChangeFocus to match
> PPAPI.
> > I named it something else because DidChangeFocus doesn't quite work (see CL
> > description).
> 
> I like this in general. I'll take a closer look in a day or two, and I'll also
> test it with Wesnoth.

Do you wire the new interface functions to Plugin::DidChangeFocus and
Plugin::DidChangeView (view.IsPageVisible()) ? I do that and everything seems to
work fine, except for one glitch: I don't get DidChangeFocus when clicking
outside of the browser window, even though the whole browser loses focus.

Seems like a browser bug, unless I'm using the interface in a wrong way.

Btw, your recent optimizations of HTTP2Mount and MainThreadRunner seem to have
noticably improved Wesnoth performance, mostly loading times. It was "fast
enough" before (with pre-cached data), but now it feels as fast as the desktop
version. Thanks!

[davidben, 2012-03-30 18:28:33]

On 2012/03/30 15:01:28, Evgeniy Stepanov wrote:
> Do you wire the new interface functions to Plugin::DidChangeFocus and
> Plugin::DidChangeView (view.IsPageVisible()) ? I do that and everything seems
to
> work fine, except for one glitch: I don't get DidChangeFocus when clicking
> outside of the browser window, even though the whole browser loses focus.
> 
> Seems like a browser bug, unless I'm using the interface in a wrong way.

Right, example wiring would make sense here. :-) This is how I wired them up:

https://github.com/davidben/uqm/commit/047a5d5730b006c4ce9d5f7773a6b9c94b5bfce4

Yeah, I think the DidChangeFocus thing might be a bug or very strange semantics
if it's intentional. DidChangeFocus seems to only trigger when WebKit-internal
focus changes and doesn't notice when the window or tab changes. DOM focus and
blur events work just fine, so I just used those. I also didn't use the new
DidChangeView because it was only added in pepper 18. I assume it works though.
(And I guess 18 did hit stable a couple days ago, so I may as well switch after
everyone's updated.)
 
> Btw, your recent optimizations of HTTP2Mount and MainThreadRunner seem to have
> noticably improved Wesnoth performance, mostly loading times. It was "fast
> enough" before (with pre-cached data), but now it feels as fast as the desktop
> version. Thanks!

Great! I was hoping they'd help Wesnoth too. Loading time also bugged me with
that port, but I never got around to building it and poking around. :-)

[Evgeniy Stepanov, 2012-04-03 14:14:13]

On 2012/03/30 18:28:33, David Benjamin wrote:
> On 2012/03/30 15:01:28, Evgeniy Stepanov wrote:
> > Do you wire the new interface functions to Plugin::DidChangeFocus and
> > Plugin::DidChangeView (view.IsPageVisible()) ? I do that and everything
seems
> to
> > work fine, except for one glitch: I don't get DidChangeFocus when clicking
> > outside of the browser window, even though the whole browser loses focus.
> > 
> > Seems like a browser bug, unless I'm using the interface in a wrong way.
> 
> Right, example wiring would make sense here. :-) This is how I wired them up:
> 
>
https://github.com/davidben/uqm/commit/047a5d5730b006c4ce9d5f7773a6b9c94b5bfce4
> 
> Yeah, I think the DidChangeFocus thing might be a bug or very strange
semantics
> if it's intentional. DidChangeFocus seems to only trigger when WebKit-internal
> focus changes and doesn't notice when the window or tab changes. DOM focus and
> blur events work just fine, so I just used those. I also didn't use the new
> DidChangeView because it was only added in pepper 18. I assume it works
though.
> (And I guess 18 did hit stable a couple days ago, so I may as well switch
after
> everyone's updated.)
>  
> > Btw, your recent optimizations of HTTP2Mount and MainThreadRunner seem to
have
> > noticably improved Wesnoth performance, mostly loading times. It was "fast
> > enough" before (with pre-cached data), but now it feels as fast as the
desktop
> > version. Thanks!
> 
> Great! I was hoping they'd help Wesnoth too. Loading time also bugged me with
> that port, but I never got around to building it and poking around. :-)

Committed as https://chromiumcodereview.appspot.com/9963099/
Thanks!