Add webkit{Decoded,Dropped}Frames to video element. Add webkit{Audio,Video}BytesDecoded to media element.
Created attachment 80530 [details] Patch
The trickiest bit in all this was finding everything I needed to change to add a new feature define ;-) I believe the configure.ac and GNUMakefile.am changes will be tested by the gtk bots? A potential modification to this would be to move the {audio,video}BytesDecoded attributes to the video element and add a pure bytesDecoded to the audio element. Thoughts? I'm still not sure what the best thing to do when the data is not available (which shouldn't actually be the case now as it's turned off in all ports by default).
Very interesting. Looks sane to me, but CCing others who might have more context about APUI counters like these.
Comment on attachment 80530 [details] Patch Looks good overall, but I am torn about having the compile flag *only* checked in the IDL. We only need to hide the properties from JavaScript for a port that doesn't implement this, and I don't think it is necessary to surround all of the code in every class, I think it could be useful to have it in HTMLMediaElement so it is clear to anyone looking at the code that it is a compile time feature.
Thanks! Am a little bit unclear from your comment whether you'd like me to add #if's to the implementation files or not? Also, am not sure how to test the configure.ac, GNUMakefile.am or vsprops changes. Do the bots do that?
(In reply to comment #5) > Thanks! > > Am a little bit unclear from your comment whether you'd like me to add #if's to the implementation files or not? > Sorry, my comment is completely unclear. I would prefer to have the #if in HTMLMediaElement.cpp/.h so it is easy to see that it is an opt-in feature. I don't have strong feelings about MediaPlayer and friends, either is OK. > Also, am not sure how to test the configure.ac, GNUMakefile.am or vsprops changes. Do the bots do that? You will have to babysit the build bots once the change lands to see if you broke something.
Created attachment 80805 [details] Patch
Comment on attachment 80805 [details] Patch Thanks!
I'm still unclear about why the patch is failing to apply on the gtk-ews bot. Any clues? If this is ok. Can I get a cq+ :-) Or is there some other process I'm missing (new to this...) Thx.
Comment on attachment 80805 [details] Patch Rejecting attachment 80805 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-3', 'apply-..." exit_code: 2 Last 500 characters of output: of 2 hunks FAILED -- saving rejects to file WebKitLibraries/win/tools/vsprops/FeatureDefines.vsprops.rej patching file WebKitLibraries/win/tools/vsprops/FeatureDefinesCairo.vsprops Hunk #1 FAILED at 9. Hunk #2 FAILED at 197. 2 out of 2 hunks FAILED -- saving rejects to file WebKitLibraries/win/tools/vsprops/FeatureDefinesCairo.vsprops.rej patching file configure.ac Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Eric Carlson', u'--for..." exit_code: 1 Full output: http://queues.webkit.org/results/7685714
Sigh. I have really no idea why the patch to those two files would fail to apply as they haven't been modified in 3 months. Will do some digging, but if anyone has a flash of inspiration about what I might be doing wrong I'd appreciate it...
Dan was telling me that it might have something to do with line endings. In any case, I'm sure its not your fault. Someone should be able to help you land your patch manually (all my working copies are busy at the moment...).
(In reply to comment #12) > Dan was telling me that it might have something to do with line endings. In any case, I'm sure its not your fault. Someone should be able to help you land your patch manually (all my working copies are busy at the moment...). I'll take a look shortly.
(In reply to comment #13) > (In reply to comment #12) > > Dan was telling me that it might have something to do with line endings. In any case, I'm sure its not your fault. Someone should be able to help you land your patch manually (all my working copies are busy at the moment...). > > I'll take a look shortly. Weird. I was able to apply the patch using svn-apply without issue. Is the commit-queue bot running under Windows?
I'll land this by hand for Steve Lacey.
(In reply to comment #14) > Weird. I was able to apply the patch using svn-apply without issue. Is the commit-queue bot running under Windows? Disregard this remark. I think something is up with patch(1) on GTK-ews bot.
Committed in changeset 77394 <http://trac.webkit.org/changeset/77394>.