diff options
author | nick@chromium.org <nick@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-02-02 23:31:07 +0000 |
---|---|---|
committer | nick@chromium.org <nick@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-02-02 23:31:07 +0000 |
commit | d748d0ffa9996ae58ab39c2cfdd5abbfcb6dcec4 (patch) | |
tree | af8aab17d5d6a08ba69022f408792733471da483 /skia/ext/platform_canvas.h | |
parent | 89ae13ed038c80228a532f42c92cd5de5bbc8a35 (diff) | |
download | chromium_src-d748d0ffa9996ae58ab39c2cfdd5abbfcb6dcec4.zip chromium_src-d748d0ffa9996ae58ab39c2cfdd5abbfcb6dcec4.tar.gz chromium_src-d748d0ffa9996ae58ab39c2cfdd5abbfcb6dcec4.tar.bz2 |
Change PlatformBitmap memory ownership story. Fix CopyFromBackingStore threading issues.
PlatformBitmap: restructure this class so that, on all platforms,
it is safe to use an SkBitmap derived from the PlatformBitmap
even after the PlatformBitmap is destroyed. In practice
this means changes to Linux (use a different cairo
creation routine that allows us to allocate the memory) and
Windows (the HDC is owned by PlatformBitmap, the HBITMAP
by the SkPixelRef).
CopyFromBackingStore: instead of requiring the caller to
provide a PlatformBitmap, modify the signature so that the
completion callback accepts an SkBitmap. Sometimes, the backing store
copiers will allocate a PlatformBitmap and pass its SkBitmap
to the completion callback, but this becomes merely an
implementation detail. Meanwhile, in the accelerated case,
it is not at all necessary to allocate a PlatformBitmap,
so don't.
This fixes a bug on Linux where the cairo surface context
was being freed on a thread other than the UI thread.
PlatformBitmap is basically not thread safe on Linux,
and this change fixes that. Also fixed is a Dr. Memory
GDI usage warning -- we are sure to de-select the
HBITMAP before deleting the memory DC.
Lastly, moving CopyFromBackingStore's interface to use a
callee-managed SkBitmap conditions the architecture for doing
RGBA->YUV on the GPU, prior to readback.
BUG=109963,159234,161537
Review URL: https://codereview.chromium.org/12087016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180271 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'skia/ext/platform_canvas.h')
-rw-r--r-- | skia/ext/platform_canvas.h | 11 |
1 files changed, 9 insertions, 2 deletions
diff --git a/skia/ext/platform_canvas.h b/skia/ext/platform_canvas.h index 68e00072..d8fd727 100644 --- a/skia/ext/platform_canvas.h +++ b/skia/ext/platform_canvas.h @@ -10,7 +10,9 @@ #include "base/basictypes.h" #include "skia/ext/platform_device.h" #include "skia/ext/refptr.h" +#include "third_party/skia/include/core/SkBitmap.h" #include "third_party/skia/include/core/SkCanvas.h" +#include "third_party/skia/include/core/SkPixelRef.h" namespace skia { @@ -163,6 +165,7 @@ class SK_API ScopedPlatformPaint { ScopedPlatformPaint& operator=(const ScopedPlatformPaint&); }; +// PlatformBitmap holds a PlatformSurface that can also be used as an SkBitmap. class SK_API PlatformBitmap { public: PlatformBitmap(); @@ -176,12 +179,16 @@ class SK_API PlatformBitmap { // Return the skia bitmap, which will be empty if Allocate() did not // return true. + // + // The resulting SkBitmap holds a refcount on the underlying platform surface, + // so the surface will remain allocated so long as the SkBitmap or its copies + // stay around. const SkBitmap& GetBitmap() { return bitmap_; } private: SkBitmap bitmap_; - PlatformSurface surface_; // initialized to 0 - intptr_t platform_extra_; // initialized to 0, specific to each platform + PlatformSurface surface_; // initialized to 0 + intptr_t platform_extra_; // platform specific, initialized to 0 DISALLOW_COPY_AND_ASSIGN(PlatformBitmap); }; |