| 2880df2609eba09b555ca37be04b6ad89290c765 |
|
29-Oct-2015 |
Tom Hudson <tomhudson@google.com> |
Revert "Revert "Merge remote-tracking branch 'goog/master-skia' into goog/master""
When I broke android yesterday we reverted this merge to fix the breakage.
Undoing that revert so we can pull in the fix from Skia.
/external/skia/gm/repeated_bitmap.cpp
|
| f7834221ac5342a3446b9b299398ea3ff7976946 |
|
28-Oct-2015 |
Tom Hudson <tomhudson@google.com> |
Revert "Merge remote-tracking branch 'goog/master-skia' into goog/master"
This reverts commit 0efb99a7c27bb2c4fc1a89993da5948a4e971823.
Change-Id: I971811435410091088a932f79ddbe254fd80e79d
/external/skia/gm/repeated_bitmap.cpp
|
| 7a14b310d6c618fa2151d93a43b29f9599adc32a |
|
01-Oct-2015 |
halcanary <halcanary@google.com> |
SkPDF: Implement drawImage*() properly
drawImage calls now properly embeds the original jpeg.
NOTE: drawBitmap*() calls no longer embed JPEG files when
possible (this is in advance of eliminating bitmaps backed
by encoded data). Chromium has already moved from
drawBitmap to drawImage.
Comparisons:
control:
total PDF drawImage/drawBitmap calls: 8010
total PDF jpeg images: 0
total PDF regular images: 3581
experiament:
total PDF drawImage/drawBitmap calls: 8014
total PDF jpeg images: 271
total PDF regular images: 3311
total PDF regular images: 3582 (271 + 3311)
When comparing rendered output there were perceptual
differences in the following four GMs: colorcube, emboss,
colormatrix, and tablecolorfilter. All of these differences
were improvements (that is, closer to the 8888 rendering)
due fixing a bug with colorfilters and forgetting to call
notifyPixelsChanged.
No SKPs had perceptual differences.
Total PDF size dropped from 133964 kB to 126276 kB, a 5.7%
improvement (mostly due to restoring use of JPG images in
SKPs).
BUG=skia:4370
Review URL: https://codereview.chromium.org/1372783003
/external/skia/gm/repeated_bitmap.cpp
|
| 943a462fef57832e2683894bb9f2f36ac25d98f7 |
|
03-Sep-2015 |
robertphillips <robertphillips@google.com> |
Minor code cleanup (left over from prior CL)
This was requested in https://codereview.chromium.org/1309543012/ (Add new GM to directly exercise perspective bitmap drawing)
Review URL: https://codereview.chromium.org/1320673011
/external/skia/gm/repeated_bitmap.cpp
|
| 125960152dfd7f2aba4c2239131bdf75d9ac2705 |
|
29-Jul-2015 |
caryclark <caryclark@google.com> |
make tests portable by using 565 compatible colors
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1262703002
/external/skia/gm/repeated_bitmap.cpp
|
| a8448bc3dfe0f2e768838b4416fb3ebf823b694e |
|
17-Apr-2015 |
halcanary <halcanary@google.com> |
PDF: Correctly embed JPEG images directly into PDF output.
We only embed images with YUV planes. That should only grab the
subset of color JPEGs supported by PDF.
BUG=skia:3180
Review URL: https://codereview.chromium.org/1025773002
/external/skia/gm/repeated_bitmap.cpp
|
| 1b5c604d9d344537941b11b136348edfc39f236c |
|
18-Feb-2015 |
halcanary <halcanary@google.com> |
PDF: Add (low-memory) SkPDFBitmap class
Also: Add SkDeflateWStream and associated unit tests.
SkPDFBitmap is a replacement for SkPDFImage. As of now, it only
supports 8888 bitmaps (the most common case).
SkPDFBitmap takes very little extra memory (aside from refing the
bitmap's pixels), and its emitObject() does not cache any data.
The SkPDFBitmap::Create function will check the canon for duplicates.
This can reduce the size of the output PDF.
Motivation: this gives another ~40% decrease in PDF memory overhead
TODO: Support other ColorTypes and scrap SkPDFImage.
BUG=skia:3030
Review URL: https://codereview.chromium.org/918813002
/external/skia/gm/repeated_bitmap.cpp
|