aboutsummaryrefslogtreecommitdiffhomepage
path: root/include
diff options
context:
space:
mode:
authorGravatar commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>2013-11-06 10:08:30 +0000
committerGravatar commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>2013-11-06 10:08:30 +0000
commit6e3e42296b0d7a93325146d9c9a7e23ef90760fe (patch)
tree7b9c3f75c7e8da1e5c3f0510e8173b0fdbd490bb /include
parent6006d0f8c4f19d19a12de20826f731f52ac822a7 (diff)
Break up SkLazyPixelRef functionally into class hierarchy.
The reason for this CL is to allow greater decoder flexibility. Chrome currently uses its own decoding functions. These allow for greater flexibility in dealing with images with multiple frames or partial data. The DecodeProc function was not flexible enough to handle these. Instead of asking the decoder to squeeze everything into the DecodeProc, we now ask the downstream library to inherit from SkCachingPixelRef. If WebKit's LazyDecodingPixelRef is re-tooled to inherit from SkCachingPixelRef, then it can make use of Skia's caching ability while still allowing it to deal with multiple frames, scaling, subsetting, and partial data. - The abstract SkCachingPixelRef class handles caching the decoded data in a SkScaledImageCache. This class relies on the virtual functions onDecodeInfo() and onDecode() to do the actual decoding of data. - The SkLazyCachingPixelRef class is derived from SkCachingPixelRef. It provides an implementation of onDecodeInfo() and onDecode() in terms of calls to a SkBitmapFactory::DecodeProc function. It also provides an Install() static method which installs a new SkLazyCachingPixelRef into a SkBitmap. SkLazyCachingPixelRef exists for two reasons: to test SkCachingPixelRef within Skia and as an example for downstream developers to make their own classes that inherit from SkCachingPixelRef. - The CachedDecodingPixelRefTest was updated to test the SkLazyCachingPixelRef class and indirectly the SkCachingPixelRef class. BUG= R=reed@google.com, scroggo@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/54203006 git-svn-id: http://skia.googlecode.com/svn/trunk@12149 2bbb7eff-a529-9590-31e7-b0007b416f81
Diffstat (limited to 'include')
-rw-r--r--include/core/SkBitmap.h2
-rw-r--r--include/core/SkImage.h3
2 files changed, 5 insertions, 0 deletions
diff --git a/include/core/SkBitmap.h b/include/core/SkBitmap.h
index 59b6482735..64f2e24133 100644
--- a/include/core/SkBitmap.h
+++ b/include/core/SkBitmap.h
@@ -17,6 +17,7 @@
#include "SkPoint.h"
#include "SkRefCnt.h"
+struct SkImageInfo;
struct SkIRect;
struct SkRect;
class SkPaint;
@@ -259,6 +260,7 @@ public:
kPremul_SkAlphaType);
}
+ bool setConfig(const SkImageInfo& info, size_t rowBytes = 0);
/** Use this to assign a new pixel address for an existing bitmap. This
will automatically release any pixelref previously installed. Only call
diff --git a/include/core/SkImage.h b/include/core/SkImage.h
index 97dc7999e5..ae8bbf5d50 100644
--- a/include/core/SkImage.h
+++ b/include/core/SkImage.h
@@ -47,6 +47,9 @@ struct SkImageInfo {
SkAlphaType fAlphaType;
};
+bool operator==(const SkImageInfo& lhs, const SkImageInfo& rhs);
+bool operator!=(const SkImageInfo& lhs, const SkImageInfo& rhs);
+
/**
* SkImage is an abstraction for drawing a rectagle of pixels, though the
* particular type of image could be actually storing its data on the GPU, or