diff options
author | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-05 18:00:28 +0000 |
---|---|---|
committer | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-05 18:00:28 +0000 |
commit | 937a4583a290d621f50c1788346584f79aab5a29 (patch) | |
tree | 789028cbf29f2fb1967ff3dc65412e6b2f9dcd95 /breakpad | |
parent | c66a0ebbcbd5792cf58ffd4944cc493f1ffe3ea9 (diff) | |
download | chromium_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