Conversions between WebInputEvent <--> PlatformEvent

[Dave Tapuska]

I've got another case of getting burned by an error in the conversion between WebInputEvent and PlatformEvent.

Has anyone ever proposed the idea just making PlatformEvent being a C++ wrapper on top of the WebInputEvents?

This might get us a little closer to mojo'ifying the code; since the PlatformEvents would essentially be our APIs for the backing data.

Perhaps it isn't worth it though.

So something like:

class PlatformGestureEvent : public PlatformEvent {

public:

PlatformGestureEvent(const WebGestureEvent& payload)

: PlatformEvent(&m_data),

, m_data(payload)

{

}

bool inertial() const

{

   switch (m_data.type)

     case GestureScrollUpdate:

       return m_data.data.scrollUpdate.inerital;

     case GestureScrollEnd:

       return m_data.data.scrollEnd.inertial;

      default:

       ASSERT_NOT_REACHED();

    }

}

private:

   WebGestureEvent m_data;

};

[Rick Byers]

+esprehn for Onion Soup.  Last I heard, the plan was to eliminate the platform event layer entirely by merging it with the web layer.  I don't yet know exactly how that will look.  The main reason they're still separate today is that the web layer is constrained by our IPC limitations (POD types).  I can't think of any reason why (after the blink folk) PlatformEvent types couldn't just be wrappers around WebInputEvent types.  We kind of started down that path by putting WebPointerProperties into PlatformTouchPoint and PlatformMouseEvent.  But I don't have a solid enough handle on what the post Onion Soup / mojo code will look like exactly to know whether your proposal is a good step in that direction or not.  Perhaps it's less work overall to just start taking steps directly towards the long-term goal instead?

Anyway I don't have any problem with making the platform input events be wrappers around the WebInputEvents if you feel it's a useful simplification.

Rick

[Dave Tapuska]

I don't have a good grasp on what mojo planning is going on above and beyond simple services getting going directly into the platform layer and avoiding the render thunks.

For input it is a little more complex because of the shared code space in render/* and blink...

I could see a plan like this:

1) Remove the conversions from WebInputEvent<-->PlatformEvent; making PlatformEvent a mere C++ wrapper.

2) Rename PlatformEvent into something more logical (perhaps just InputEvent) and move it to be higher in the stack something in content/renderer that could be imported into Blink.

3) Change the renderer to deal with this new type of event natively (and not just WebInputEvent's)

4) Write a mojo interface that matches this InputEvent so that you could test (WebInputEvent with InputEvent C++ wrapper) and (InputEvent mojo C++ gen object) independently.

As I presume we will have to do a lot of work around ensuring our latency doesn't regress if we started piping input events over mojo from the browser process.

dave.

[Rick Byers]

Sounds like a reasonable plan to me.  Maybe worth writing up a short design doc and getting feedback from Onion Soup folks?  There's definitely a bunch of value to be had by eliminating a layer here and cleaning up the interfaces (eg. lack of encapsulation in WebInputEvent is also occasionally an issue), so I'm supportive of any work in this direction...

[Elliott Sprehn]

My first step was going to be moving WebInputEvent and its friends into platform/. I tried it a few weeks ago but it touched hundreds of files all over the entire src/ tree: https://codereview.chromium.org/1756603004

My next attempt was going to be to move the actual source files but leave "proxy" headers in public/web with a comment saying they shouldn't contain any real code.

If we move them down into platform/ they can also be used in all layers of blink.