Bug 94238

Summary: [chromium] Add additional fields to WebGestureEvent
Product: WebKit Reporter: Rick Byers <rbyers>
Component: DOMAssignee: Rick Byers <rbyers>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, dglazkov, fishd, jamesr, rjkroege, tkent+wkapi, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 93123    
Attachments:
Description Flags
Patch
none
Patch none

Rick Byers
Reported 2012-08-16 12:39:51 PDT
To fix bug 93123, we're going to add a few gesture-type-specific fields to WebGestureEvent and PlatformGestureEvent. The first step is to add these new fields to WebGestureEvent so that chromium can start setting them (redundantly with deltaX/deltaY temporarily). Only once chromium is writing to the new fields, can I submit a CL to stop overloading deltaX/deltaY.
Attachments
Patch (3.00 KB, patch)
2012-08-16 13:08 PDT, Rick Byers
no flags
Patch (3.20 KB, patch)
2012-08-19 07:48 PDT, Rick Byers
no flags
Rick Byers
Comment 1 2012-08-16 13:08:43 PDT
WebKit Review Bot
Comment 2 2012-08-16 13:14:00 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Adam Barth
Comment 3 2012-08-16 13:33:45 PDT
Thanks.
James Robinson
Comment 4 2012-08-16 13:34:06 PDT
What about using a union instead of growing the type's size even further, if these fields don't overlap?
Adam Barth
Comment 5 2012-08-16 13:37:57 PDT
rjkroege, should we respond to jamesr's question before landing the patch?
Rick Byers
Comment 6 2012-08-16 13:40:14 PDT
(In reply to comment #4) > What about using a union instead of growing the type's size even further, if these fields don't overlap? See bug 93123 - abarth@ said to prefer adding more fields over a union. I did a bunch of measurements to confirm that the performance impact (even with 1024 new fields) is negligible.
Robert Kroeger
Comment 7 2012-08-16 13:46:01 PDT
abarth@ jamesr@: Sorry for being too eager. Fixed.
Rick Byers
Comment 8 2012-08-16 13:47:44 PDT
Also note that we don't use a union anywhere else in WebInputEvent.h. For example, WebMouseEvent has a clickCount field that's only used for some event types (MouseDown, MouseUp, Click). I also need to update PlatformGestureEvent. I don't see a lot of unions in WebCore code, I wasn't sure if they were frowned upon. The cleaner option is to have a bunch of sub-classes, but that adds a lot of complexity for almost no practical benefit.
James Robinson
Comment 9 2012-08-16 14:21:07 PDT
Subclasses are the same as unions practically speaking, just a different way to spell it. It's not a huge difference - but it does add up. Piling on extra fields is OK, but IMO it's sloppy coding.
Rick Byers
Comment 10 2012-08-16 14:50:05 PDT
(In reply to comment #9) > Subclasses are the same as unions practically speaking, just a different way to spell it. I agree (although in practice the difference in the amount of code, and likelihood of accidentally violating type safety can be quite different). > It's not a huge difference - but it does add up. Piling on extra fields is OK, but IMO it's sloppy coding. It's up to you and abarth - I'm happy to take whichever approach you guys agree is better. Unions (or subclassing) was our first plan. After doing the perf measurements, I can't help but find myself thinking the shorter/simpler code is a better trade-off. IMHO a simpler but more wasteful approach isn't always sloppiness if an explicit cost/benefit trade-off is being made. Anyway, like I said - let me know which approach you guys believe is better.
Adam Barth
Comment 11 2012-08-18 22:45:15 PDT
I don't think it's a big deal one way or another. I'm happy to defer to James here if he feels strongly. I suspect it's not an issue we should get hung up on one way or another.
Rick Byers
Comment 12 2012-08-19 07:45:51 PDT
(In reply to comment #11) > I don't think it's a big deal one way or another. I'm happy to defer to James here if he feels strongly. I suspect it's not an issue we should get hung up on one way or another. Agreed. It may be more contentious for PlatformGestureEvent, but there's no reason we need to choose the same solution there. It's trivial to use a union here in WebGestureEvent. Patch forthcoming.
Rick Byers
Comment 13 2012-08-19 07:48:14 PDT
James Robinson
Comment 14 2012-08-19 12:11:32 PDT
Comment on attachment 159294 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=159294&action=review > Source/WebKit/chromium/src/WebInputEvent.cpp:63 > + int gestureData[14]; this size growth is temporary, right?
WebKit Review Bot
Comment 15 2012-08-19 12:49:33 PDT
Comment on attachment 159294 [details] Patch Clearing flags on attachment: 159294 Committed r125981: <http://trac.webkit.org/changeset/125981>
WebKit Review Bot
Comment 16 2012-08-19 12:49:37 PDT
All reviewed patches have been landed. Closing bug.
Rick Byers
Comment 17 2012-08-19 19:00:20 PDT
Thanks James. (In reply to comment #14) > (From update of attachment 159294 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=159294&action=review > > > Source/WebKit/chromium/src/WebInputEvent.cpp:63 > > + int gestureData[14]; > > this size growth is temporary, right? Yes, by simplifying the bounding box stuff (x/y was unused) I'll get this down to 8 once I update chromium.
James Robinson
Comment 18 2012-08-19 20:32:13 PDT
OK great! Feel free to CC me on the chromium patches if you need any reviews on that side.
Lucas Forschler
Comment 19 2019-02-06 09:18:25 PST
Mass move bugs into the DOM component.
Note You need to log in before you can comment on or make changes to this bug.