Summary: | [GTK] Download progress notification should be throttled, for the benefit of download managers | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Gustavo Noronha (kov) <gustavo> | ||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | xan.lopez | ||||
Priority: | P2 | Keywords: | Gtk | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Gustavo Noronha (kov)
2009-06-03 15:32:11 PDT
Created attachment 30932 [details]
Throttle download speed.
WebKit/gtk/ChangeLog | 16 ++++++++++++++++
WebKit/gtk/webkit/webkitdownload.cpp | 26 ++++++++++++++++++++++----
2 files changed, 38 insertions(+), 4 deletions(-)
Comment on attachment 30932 [details]
Throttle download speed.
Looks good to me. I wonder if current-size should be throttled too, in case it reports changes more often than needed (and uses too much CPU in doing so).
Landed as r44485. About throttling current-size, my original patch did that, but the high CPU usage we experienced was not caused by the signal emissions (notice we already have signal emissions, and many function calls on that code path), but by the download manager updating the UI based on the emissions. I decided to not propose throttling the emissions of current-size and total-size, because then those properties will work for whoever wants to follow the progress more closely, while download managers can keep using the convenience property without having to do throttling themselves. Thoughts on that? |