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
Fixes the cases where clip stack reduction would cause clip to be
re-rendered to stencil for each draw call. This causes unneeded
slowdown.
Stencil cache would not be used because the clip stack generation id communicated
by the clip stack element list would be invalid. This happended due to
a) clip stack reduction creating new elements in the element list.
b) purging logic removing the generation id, but reduction logic
selecting already purged element, and thus the generation id, as
the representative state of the clip.
Cases of a) where reduction would flatten the stack to a single new
element were fixed by assigning the generation id of the top-most
element of the clip stack as the generation id of the new
element. This is not strictly minimal, but enables more caching than
using invalid id.
Cases of a) where reduction would substitute a stack element with a
new element the generation id of the substituted element is used.
The b) part was fixed by removing the purging logic. It was not
exactly correct, as the previously purged states were actually
used. The purging was not used for anything.
Changes SkClipStack API to highlight that invalid generation id is
never returned by SkClipStack. Empty stacks are wide open. Changes the
clients to reflect this.
Fixes a crash when not passing anti-alias out parameter to
GrReducedClip::ReduceClipStack. The crash is not exercised in the
current code.
Committed: http://code.google.com/p/skia/source/detail?r=12084R=bsalomon@google.com, robertphillips@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/48593003
git-svn-id: http://skia.googlecode.com/svn/trunk@12127 2bbb7eff-a529-9590-31e7-b0007b416f81
Fixes the cases where clip stack reduction would cause clip to be
re-rendered to stencil for each draw call. This causes unneeded
slowdown.
Stencil cache would not be used because the clip stack generation id communicated
by the clip stack element list would be invalid. This happended due to
a) clip stack reduction creating new elements in the element list.
b) purging logic removing the generation id, but reduction logic
selecting already purged element, and thus the generation id, as
the representative state of the clip.
Cases of a) where reduction would flatten the stack to a single new
element were fixed by assigning the generation id of the top-most
element of the clip stack as the generation id of the new
element. This is not strictly minimal, but enables more caching than
using invalid id.
Cases of a) where reduction would substitute a stack element with a
new element the generation id of the substituted element is used.
The b) part was fixed by removing the purging logic. It was not
exactly correct, as the previously purged states were actually
used. The purging was not used for anything.
Changes SkClipStack API to highlight that invalid generation id is
never returned by SkClipStack. Empty stacks are wide open. Changes the
clients to reflect this.
Fixes a crash when not passing anti-alias out parameter to
GrReducedClip::ReduceClipStack. The crash is not exercised in the
current code.
R=bsalomon@google.com, robertphillips@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/48593003
git-svn-id: http://skia.googlecode.com/svn/trunk@12084 2bbb7eff-a529-9590-31e7-b0007b416f81
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
This adds an invalidation listener mechanism to SkPixelRef to let it send this message while still staying ignorant of who's listening.
These messages are tricky to deliver. The SkPixelRefs they originates from and the GrResourceCaches they ultimately end up at may be on different threads; neither class is threadsafe; their object lifetimes are totally independent; it's a many-senders-to-many-receivers relation; and neither codebase should really know about the other.
So I've added a per-message-type global message bus to broadcast messages to threadsafe inboxes. Anyone can post() a message, which will show up in all the inboxes of that type, read whenever the inbox's owner calls poll(). The implementation is _dumb_; it can be improved in several dimensions (inbox size limits, lock-free message delivery) if we find the need.
I took some care to make sure not to send the invalidation message for any SkPixelRef that's sharing a generation ID with another SkPixelRef.
BUG=
R=bsalomon@google.com, scroggo@google.com, reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/26734003
git-svn-id: http://skia.googlecode.com/svn/trunk@11949 2bbb7eff-a529-9590-31e7-b0007b416f81
This returns true if (1) the picture has finished recording and
(2) this picture or any picture drawn into it refers to any bitmaps.
It allows clients doing complicated manipulations of the picture to
early-out when there are no bitmaps present.
BUG=303281
R=reed@google.com
git-svn-id: http://skia.googlecode.com/svn/trunk@11935 2bbb7eff-a529-9590-31e7-b0007b416f81
