1. 398337b Revert "remvoe duplicate impl for SkImageInfo flattening" by reed@google.com · 11 years ago
  2. a0d183d Revert "Revert of https://codereview.chromium.org/108773003/" by reed@google.com · 11 years ago
  3. ff9c6c9 Revert of https://codereview.chromium.org/108773003/ by commit-bot@chromium.org · 11 years ago
  4. f3aead2 remvoe duplicate impl for SkImageInfo flattening by reed@google.com · 11 years ago
  5. 6a32add Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap.""""" by reed@google.com · 11 years ago
  6. 6965a0a PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap."""" by reed@google.com · 11 years ago
  7. 2ebc10d Revert "Revert "Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap.""" by reed@google.com · 11 years ago
  8. 473f0aa Revert "Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap."" by reed@google.com · 11 years ago
  9. 5b132b2 Revert "PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap." by reed@google.com · 11 years ago
  10. 3e89524 PixelRef now returns (nearly) everything that is currently in SkBitmap. The goal is to refactor bitmap later to remove redundancy, and more interestingly, remove the chance for a disconnect between the actual (pixelref) rowbytes and config, and the one claimed by the bitmap. by reed@google.com · 11 years ago
  11. bbfe454 Apply matrix early in draw bitmap by commit-bot@chromium.org · 11 years ago
  12. e982187 Revert "Apply matrix early in draw bitmap" by scroggo@google.com · 11 years ago
  13. 25e5a20 Apply matrix early in draw bitmap by commit-bot@chromium.org · 11 years ago
  14. 1aa54bf Added ctm matrix to GPU path by commit-bot@chromium.org · 11 years ago
  15. 40ea172 Initialize the matrix used when recursing from a GPU image filter -> raster image filter. by senorblanco@chromium.org · 11 years ago
  16. 7b32070 Implement offset for GPU filter path. Although we can't yet use this in Blink for FEOffset, due to SVG semantics, we can use it to support crop rect (upcoming patch). by commit-bot@chromium.org · 11 years ago
  17. d043cce Allow single-pass filters (which use asNewEffect()) to participate in the image filter DAG. This was done by introducing the SkSinglePassImageFilter abstract base class, which implements canFilterImageGPU() and filterImageGPU() on behalf of the derived class. The derived class still only needs to asNewEffect(). This allows us to recurse on the filter input in SkSinglePassImageFilter::onFilterImageGPU(). It also allows us to remove any knowledge of single-pass image filters from SkGpuDevice and from the SkImageFilter base class as well. by senorblanco@chromium.org · 11 years ago[Renamed (95%) from src/effects/SkImageFilterUtils.cpp]
  18. c3ecf65 Speculative change to SkImageFilterUtils.cpp to try to get compiling in Chrome by robertphillips@google.com · 12 years ago
  19. c2594f4 This changes the signature of SkImageFilter::filterImageGPU() to use SkBitmaps for input and output, and removes the rect param. This allows us to return textures which are larger than the actual result, such as when GrAutoScratchTextures are used. The SkBitmap's size represents the active region, while the GrTexture's size is the full texture size. by senorblanco@chromium.org · 12 years ago