summaryrefslogtreecommitdiffstats
path: root/breakpad
diff options
context:
space:
mode:
authoragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-02-05 18:00:28 +0000
committeragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-02-05 18:00:28 +0000
commit937a4583a290d621f50c1788346584f79aab5a29 (patch)
tree789028cbf29f2fb1967ff3dc65412e6b2f9dcd95 /breakpad
parentc66a0ebbcbd5792cf58ffd4944cc493f1ffe3ea9 (diff)
downloadchromium_src-937a4583a290d621f50c1788346584f79aab5a29.zip
chromium_src-937a4583a290d621f50c1788346584f79aab5a29.tar.gz
chromium_src-937a4583a290d621f50c1788346584f79aab5a29.tar.bz2
POSIX: Backing store scrolling.
In the long term, we plan to get rid of all this code and "do things properly". However, for now we are implementing several shortcuts to get something which can render. Part one of this was BitmapWireData (r9065) which transported updates from the renderer over the IPC channel. This patch implements the fast-scrolling path, slowly. It might seem that this is something which Skia should be doing. However, copying from one bitmap to the same bitmap needs to be handled very differently from bitblitting from one to another to save writing to locations that you'll need to read from later on. I can't see any indication in the Skia code that it handles this case so, in order to get something working quickly, we write our own, small, bitblitter. Since this code hasn't been tested, it's almost certainly buggy. However, we don't get to test it until we get a little more of the browser up and running. Review URL: http://codereview.chromium.org/21050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9223 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'breakpad')
0 files changed, 0 insertions, 0 deletions