summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorstuartmorgan@chromium.org <stuartmorgan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-03-26 18:55:09 +0000
committerstuartmorgan@chromium.org <stuartmorgan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-03-26 18:55:09 +0000
commit779b8811261f858eeb19d383ab3647775223c58f (patch)
tree0c32670d05cf81da511bcafb4075d0596954d8ae /net
parentd20dd3d2b4e62d45b1ecae10d4e9cf743d6b21ed (diff)
downloadchromium_src-779b8811261f858eeb19d383ab3647775223c58f.zip
chromium_src-779b8811261f858eeb19d383ab3647775223c58f.tar.gz
chromium_src-779b8811261f858eeb19d383ab3647775223c58f.tar.bz2
Add a faster path for QuickDraw plugin drawing for limited use.
The current approcah for QuickDraw plugins--letting them draw into an actual window and then scraping the contents out--is more correct than our original approach, which was to give plugins a port pointing to a pixel buffer instead of the window. Unfortunately, it's also substantially slower to scrape a window than to copy pixel buffers. Most of the time, the old way is good enough for QuickTime, and gives us substantially better framerates. This change makes QuickTime use a hybrid approach, using the fast path when possible, and the slow path when necessary. The primary situations when we need the slow path are: - During event handling - When we need the controls re-painted The are a couple of edge-case event handling regressions, and the time slider seems to move more jerkily, but the improvent in framerate makes it a worthwhile tradeoff (e.g., a large trailer goes from ~25 fps to the full 50). BUG=37968 TEST=Play QuickTime movies; playback should be smoother, and there should be no serious regressions over previous versions. Review URL: http://codereview.chromium.org/1333005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42794 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions