| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
R=jvanverth@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/192783002
git-svn-id: http://skia.googlecode.com/svn/trunk@13724 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
| |
BUG=
R=scroggo@google.com
Review URL: https://codereview.chromium.org/105893012
git-svn-id: http://skia.googlecode.com/svn/trunk@12958 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
| |
array.
R=bungeman@google.com
Review URL: https://codereview.chromium.org/15070011
git-svn-id: http://skia.googlecode.com/svn/trunk@9182 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using an SkFlatDictionary to flatten shaders, the
dictionary can try to insert a duplicate bitmap shader
that uses a bitmap which has been removed from the
bitmap heap.
This change was originally suggested by junov in
https://codereview.appspot.com/6713048/.
Add a test to verify that deferring the owners works.
Without the change to bitmap heap the test would fail
(and crash in debug mode).
Also remove an unused function from SkFlatDictionary.
BUG=http://code.google.com/p/chromium/issues/detail?id=143923
Review URL: https://codereview.appspot.com/6842051
git-svn-id: http://skia.googlecode.com/svn/trunk@6471 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
| |
https://codereview.appspot.com/6465078/)
This CL is part I of IV (I broke down the 1280 files into 4 CLs).
Review URL: https://codereview.appspot.com/6485054
git-svn-id: http://skia.googlecode.com/svn/trunk@5262 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
| |
http://codereview.appspot.com/6453127/
git-svn-id: http://skia.googlecode.com/svn/trunk@5123 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Required adding a new feature to SkBitmapHeap, allowing it to defer
adding owners, since sometimes we flatten a shader, but then do not
unflatten it, since we already had a copy in the heap, so the owners
never get removed.
Reviewed at https://codereview.appspot.com/6464053/
Review URL: https://codereview.appspot.com/6465047
git-svn-id: http://skia.googlecode.com/svn/trunk@5082 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thank you to Android build, for catching the problem, which would
show up elsewhere. Now we access entry->fStorageSlot before
deleting entry.
(Original message:)
Use the SkBitmapHeap to handle SkBitmaps in SkGPipe cross process.
Required moving the LRU handles from SkBitmapHeapEntry to LookupEntry.
Allows simplification of drawBitmap* calls in SkGPipeCanvas.
Review URL: https://codereview.appspot.com/6453113
git-svn-id: http://skia.googlecode.com/svn/trunk@5081 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@5067 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
| |
Required moving the LRU handles from SkBitmapHeapEntry to LookupEntry.
Allows simplification of drawBitmap* calls in SkGPipeCanvas.
Review URL: https://codereview.appspot.com/6460073
git-svn-id: http://skia.googlecode.com/svn/trunk@5063 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the single process (or hypothetical cross process/shared address
space) mode, SkGPipe now uses SkBitmapHeap instead of SharedHeap.
Still need to use the shared heap for shaders as well as for cross
process.
TEST=PipeTest
Review URL: https://codereview.appspot.com/6461059
git-svn-id: http://skia.googlecode.com/svn/trunk@5008 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
Refactor Picture and Pipe bitmap storage into common data structure
Update SkFlattenable buffers to be more modular.
This CL is an effort to stage the conversion to named
parameters for all SkFlattenable commands. This particular
stage only does the following two things...
1. Move flattenable buffers from SkFlattenable.h into
their own header.
2. Update and Add new read write methods for better clarity
and convenience.
BUG=
Review URL: https://codereview.appspot.com/6445079
git-svn-id: http://skia.googlecode.com/svn/trunk@4994 2bbb7eff-a529-9590-31e7-b0007b416f81
|