RESOLVED FIXED 65039
Update Chromium DRT to output binary (instead of base64-encoded) data for web audio testing
https://bugs.webkit.org/show_bug.cgi?id=65039
Summary Update Chromium DRT to output binary (instead of base64-encoded) data for web...
Chris Rogers
Reported 2011-07-22 11:50:32 PDT
Update Chromium DRT to output binary (instead of base64-encoded) data for web audio testing
Attachments
Patch (18.05 KB, patch)
2011-07-22 12:13 PDT, Chris Rogers
no flags
Patch (16.62 KB, patch)
2011-07-25 13:16 PDT, Chris Rogers
tony: review+
Chris Rogers
Comment 1 2011-07-22 12:13:01 PDT
Chris Rogers
Comment 2 2011-07-22 12:15:45 PDT
The WebArrayBufferView class is essentially boilerplate code similar to our other WebKit wrapper classes, such as WebRange...
Tony Chang
Comment 3 2011-07-22 16:31:32 PDT
+fishd since this adds a new WebKit API class.
Tony Chang
Comment 4 2011-07-22 16:38:31 PDT
Comment on attachment 101753 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101753&action=review LGTM, but let's wait for darin to OK the API changes. > LayoutTests/ChangeLog:4 > +2011-07-22 Chris Rogers <crogers@google.com> > + > + Update Chromium DRT to output binary (instead of base64-encoded) data for web audio testing > + https://bugs.webkit.org/show_bug.cgi?id=65039 From a different change?
Darin Fisher (:fishd, Google)
Comment 5 2011-07-22 16:42:38 PDT
Comment on attachment 101753 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101753&action=review I just reviewed the Chromium WebKit API changes. > Source/WebKit/chromium/public/WebArrayBufferView.h:47 > + WebArrayBufferView(const WebArrayBufferView& r) : m_private(0) { assign(r); } nit: the variable name "r" is an odd choice. normally, a letter is chosen from the typename. in this case "v" might make sense. > Source/WebKit/chromium/public/WebArrayBufferView.h:60 > + WEBKIT_API unsigned byteLength() const; isn't it valuable to expose byteOffset() too? can't the view be a slice at a non-zero offset? > Source/WebKit/chromium/public/WebArrayBufferView.h:62 > + WebArrayBufferView(const WTF::PassRefPtr<WebCore::ArrayBufferView>&); these should be guarded with #if WEBKIT_IMPLEMENTATION so that no one outside of the webkit implementation can use them. > Source/WebKit/chromium/public/WebArrayBufferView.h:68 > + WebArrayBufferViewPrivate* m_private; the "new way" is to just use the WebCore type here and ditch the WebFooPrivate type. you should also be using WebPrivatePtr<T> to help you with the reference counting and boilerplate associated with wrapping a WebCore reference counted type. > Source/WebKit/chromium/src/WebBindings.cpp:298 > + nit: extra new line should be deleted
Chris Rogers
Comment 6 2011-07-25 13:16:58 PDT
Chris Rogers
Comment 7 2011-07-25 13:18:44 PDT
Comment on attachment 101753 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101753&action=review >> Source/WebKit/chromium/public/WebArrayBufferView.h:47 >> + WebArrayBufferView(const WebArrayBufferView& r) : m_private(0) { assign(r); } > > nit: the variable name "r" is an odd choice. normally, a letter is chosen > from the typename. in this case "v" might make sense. FIXED >> Source/WebKit/chromium/public/WebArrayBufferView.h:60 >> + WEBKIT_API unsigned byteLength() const; > > isn't it valuable to expose byteOffset() too? can't the view be a slice > at a non-zero offset? Good point -- added byteOffset() >> Source/WebKit/chromium/public/WebArrayBufferView.h:62 >> + WebArrayBufferView(const WTF::PassRefPtr<WebCore::ArrayBufferView>&); > > these should be guarded with #if WEBKIT_IMPLEMENTATION so that no one outside of > the webkit implementation can use them. FIXED >> Source/WebKit/chromium/public/WebArrayBufferView.h:68 >> + WebArrayBufferViewPrivate* m_private; > > the "new way" is to just use the WebCore type here and ditch the > WebFooPrivate type. you should also be using WebPrivatePtr<T> to > help you with the reference counting and boilerplate associated > with wrapping a WebCore reference counted type. FIXED >> Source/WebKit/chromium/src/WebBindings.cpp:298 >> + > > nit: extra new line should be deleted FIXED >> LayoutTests/ChangeLog:4 >> + https://bugs.webkit.org/show_bug.cgi?id=65039 > > From a different change? Sorry - FIXED
Darin Fisher (:fishd, Google)
Comment 8 2011-07-25 14:50:38 PDT
Comment on attachment 101899 [details] Patch WebKit API changes LGTM
Chris Rogers
Comment 9 2011-07-25 15:16:49 PDT
Note You need to log in before you can comment on or make changes to this bug.