Allow capturing several canvas frames in a row. Patch to follow.
Created attachment 184227 [details] Patch
Created attachment 184228 [details] Screenshot
Comment on attachment 184227 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184227&action=review > Source/WebCore/inspector/front-end/CanvasProfileView.js:293 > + setTimeout(this._requestTraceLog.bind(this), 500); why 500?
Comment on attachment 184227 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184227&action=review >> Source/WebCore/inspector/front-end/CanvasProfileView.js:293 >> + setTimeout(this._requestTraceLog.bind(this), 500); > > why 500? just a number :) any concerns/ideas?
Comment on attachment 184227 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184227&action=review >>> Source/WebCore/inspector/front-end/CanvasProfileView.js:293 >>> + setTimeout(this._requestTraceLog.bind(this), 500); >> >> why 500? > > just a number :) any concerns/ideas? Why do you have this delay? Why do you use magic numbers?
(In reply to comment #5) > (From update of attachment 184227 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=184227&action=review > > >>> Source/WebCore/inspector/front-end/CanvasProfileView.js:293 > >>> + setTimeout(this._requestTraceLog.bind(this), 500); > >> > >> why 500? > > > > just a number :) any concerns/ideas? > > Why do you have this delay? Why do you use magic numbers? We have an alive trace log which we must fetch periodically from the backend. To send a new request right away seems too inefficient, thus I timeout a bit.
Committed r140678: <http://trac.webkit.org/changeset/140678>