Commit Graph

10 Commits

Author SHA1 Message Date
Brian Salomon
9241a6d394 Reland "Reland "SkSurface asynchronous read APIs allow client to extend pixel lifetime""
This is a reland of 6fc04f88a8

Original change's description:
> Reland "SkSurface asynchronous read APIs allow client to extend pixel lifetime"
> 
> This is a reland of ce240cc6fd
> 
> Original change's description:
> > SkSurface asynchronous read APIs allow client to extend pixel lifetime
> > 
> > Previously the pixel data passed to the client was only valid during
> > the client's callback. This meant if the client wanted to defer
> > processing of the data a copy was necessary.
> > 
> > Now we pass an object to the callback and the pixel lifetime is tied
> > to the lifetime of that object.
> > 
> > The object may be holding a GPU transfer buffer mapped. We don't assume
> > that the object will be released on the direct GrContext thread. So
> > when the object is destroyed it posts a message to a new type,
> > GrClientMappedBufferManager, hanging off the direct context. The direct
> > context will periodically check for messages and unmap and then unref
> > buffers so that they can be reused. Currently this is done in
> > GrContext::performDeferredCleanup() and GrDrawingManager::flush().
> > 
> > The old API is kept around for backwards compatibility but it is
> > reimplemented as a bridge on top of the new mechanism.
> > 
> > Also a utility function to SkImageInfo is added to directly make a new
> > info with a specified dimensions rather than passing the width and
> > height separately to makeWH().
> > 
> > Bug: chromium:973403
> > Bug: skia:8962
> > 
> > Change-Id: Id5cf04235376170142a48e90d3ecd13fd021a2a6
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245457
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Brian Salomon <bsalomon@google.com>
> 
> Bug: chromium:973403, skia:8962
> Change-Id: I5cecd36276c8b6dc942cf549c7095db2df88530c
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245678
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>

Bug: chromium:973403, skia:8962
Change-Id: Ie584c1c3ef8021c976f71b708e53871c693cc450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/246057
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
2019-10-03 19:14:22 +00:00
Ravi Mistry
cb55010652 Revert "Reland "SkSurface asynchronous read APIs allow client to extend pixel lifetime""
This reverts commit 6fc04f88a8.

Reason for revert: Chrome roll failure suspect because of:
* https://chromium-review.googlesource.com/c/chromium/src/+/1837131 (22 commits)
* https://chromium-review.googlesource.com/c/chromium/src/+/1837214 (24 commits)

Original change's description:
> Reland "SkSurface asynchronous read APIs allow client to extend pixel lifetime"
>
> This is a reland of ce240cc6fd
>
> Original change's description:
> > SkSurface asynchronous read APIs allow client to extend pixel lifetime
> >
> > Previously the pixel data passed to the client was only valid during
> > the client's callback. This meant if the client wanted to defer
> > processing of the data a copy was necessary.
> >
> > Now we pass an object to the callback and the pixel lifetime is tied
> > to the lifetime of that object.
> >
> > The object may be holding a GPU transfer buffer mapped. We don't assume
> > that the object will be released on the direct GrContext thread. So
> > when the object is destroyed it posts a message to a new type,
> > GrClientMappedBufferManager, hanging off the direct context. The direct
> > context will periodically check for messages and unmap and then unref
> > buffers so that they can be reused. Currently this is done in
> > GrContext::performDeferredCleanup() and GrDrawingManager::flush().
> >
> > The old API is kept around for backwards compatibility but it is
> > reimplemented as a bridge on top of the new mechanism.
> >
> > Also a utility function to SkImageInfo is added to directly make a new
> > info with a specified dimensions rather than passing the width and
> > height separately to makeWH().
> >
> > Bug: chromium:973403
> > Bug: skia:8962
> >
> > Change-Id: Id5cf04235376170142a48e90d3ecd13fd021a2a6
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245457
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Brian Salomon <bsalomon@google.com>
>
> Bug: chromium:973403, skia:8962
> Change-Id: I5cecd36276c8b6dc942cf549c7095db2df88530c
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245678
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>

TBR=bsalomon@google.com,brianosman@google.com

Change-Id: I9e01d1b82fb399b94292441d91da51176bb161d9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:973403, skia:8962
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245956
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
2019-10-03 09:19:24 +00:00
Brian Salomon
6fc04f88a8 Reland "SkSurface asynchronous read APIs allow client to extend pixel lifetime"
This is a reland of ce240cc6fd

Original change's description:
> SkSurface asynchronous read APIs allow client to extend pixel lifetime
> 
> Previously the pixel data passed to the client was only valid during
> the client's callback. This meant if the client wanted to defer
> processing of the data a copy was necessary.
> 
> Now we pass an object to the callback and the pixel lifetime is tied
> to the lifetime of that object.
> 
> The object may be holding a GPU transfer buffer mapped. We don't assume
> that the object will be released on the direct GrContext thread. So
> when the object is destroyed it posts a message to a new type,
> GrClientMappedBufferManager, hanging off the direct context. The direct
> context will periodically check for messages and unmap and then unref
> buffers so that they can be reused. Currently this is done in
> GrContext::performDeferredCleanup() and GrDrawingManager::flush().
> 
> The old API is kept around for backwards compatibility but it is
> reimplemented as a bridge on top of the new mechanism.
> 
> Also a utility function to SkImageInfo is added to directly make a new
> info with a specified dimensions rather than passing the width and
> height separately to makeWH().
> 
> Bug: chromium:973403
> Bug: skia:8962
> 
> Change-Id: Id5cf04235376170142a48e90d3ecd13fd021a2a6
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245457
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>

Bug: chromium:973403, skia:8962
Change-Id: I5cecd36276c8b6dc942cf549c7095db2df88530c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245678
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
2019-10-03 01:41:35 +00:00
Brian Salomon
9c219785a8 Revert "SkSurface asynchronous read APIs allow client to extend pixel lifetime"
This reverts commit ce240cc6fd.

Reason for revert: crashing in chrome unit test, abandoned context related?

Original change's description:
> SkSurface asynchronous read APIs allow client to extend pixel lifetime
> 
> Previously the pixel data passed to the client was only valid during
> the client's callback. This meant if the client wanted to defer
> processing of the data a copy was necessary.
> 
> Now we pass an object to the callback and the pixel lifetime is tied
> to the lifetime of that object.
> 
> The object may be holding a GPU transfer buffer mapped. We don't assume
> that the object will be released on the direct GrContext thread. So
> when the object is destroyed it posts a message to a new type,
> GrClientMappedBufferManager, hanging off the direct context. The direct
> context will periodically check for messages and unmap and then unref
> buffers so that they can be reused. Currently this is done in
> GrContext::performDeferredCleanup() and GrDrawingManager::flush().
> 
> The old API is kept around for backwards compatibility but it is
> reimplemented as a bridge on top of the new mechanism.
> 
> Also a utility function to SkImageInfo is added to directly make a new
> info with a specified dimensions rather than passing the width and
> height separately to makeWH().
> 
> Bug: chromium:973403
> Bug: skia:8962
> 
> Change-Id: Id5cf04235376170142a48e90d3ecd13fd021a2a6
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245457
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>

TBR=bsalomon@google.com,brianosman@google.com

Change-Id: Ic14cf07a7629b167c9f34a651aa87a0326e74207
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:973403, skia:8962
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245721
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
2019-10-02 22:51:15 +00:00
Brian Salomon
ce240cc6fd SkSurface asynchronous read APIs allow client to extend pixel lifetime
Previously the pixel data passed to the client was only valid during
the client's callback. This meant if the client wanted to defer
processing of the data a copy was necessary.

Now we pass an object to the callback and the pixel lifetime is tied
to the lifetime of that object.

The object may be holding a GPU transfer buffer mapped. We don't assume
that the object will be released on the direct GrContext thread. So
when the object is destroyed it posts a message to a new type,
GrClientMappedBufferManager, hanging off the direct context. The direct
context will periodically check for messages and unmap and then unref
buffers so that they can be reused. Currently this is done in
GrContext::performDeferredCleanup() and GrDrawingManager::flush().

The old API is kept around for backwards compatibility but it is
reimplemented as a bridge on top of the new mechanism.

Also a utility function to SkImageInfo is added to directly make a new
info with a specified dimensions rather than passing the width and
height separately to makeWH().

Bug: chromium:973403
Bug: skia:8962

Change-Id: Id5cf04235376170142a48e90d3ecd13fd021a2a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245457
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
2019-10-02 19:20:08 +00:00
Michael Ludwig
8ee6cf3691 Move SkImageFilter functionality into private SkImageFilter_Base
Bug: skia:9281
Change-Id: I189dbf652580805641f8c4b9a6587cf15a9049dd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/231256
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
2019-08-02 18:56:39 +00:00
Michael Ludwig
a861106e49 Update docs and samplecode to use new image filter factories
Bug: skia:9280
Change-Id: I03ba9bf1cc952dec77664721fdb3a311f47f7e89
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230884
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
2019-08-02 14:47:35 +00:00
Michael Ludwig
aa861a1907 Change SkMatrix::decomposeScale to use preScale
While most callers of decomposeScale only depend on the scale factors
that are returned, image filter decomposition depends on the remaining
matrix as well. Hence, the following necessary updates to work with
the new behavior of decomposeScale:

* Update imagefilter DAG sample to reflect prescaling
* Correct embedded matrix in SkApplyCTMToFilter
* Add comment to clipRectBounds() clarifying coordinate spaces and image filters

But, we want to have decomposeScale using preScale() because it then
produces a remainder matrix that can be used as the transform for the
image filter draw, instead of wrapping the image filter in an
SkMatrixImageFilter as currently done by SkApplyCTMToFilter.

Bug: skia:7211
Change-Id: If14570afb4189cebc75f3815e8ccdde05cb074e1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228438
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
2019-07-19 15:41:11 +00:00
Michael Ludwig
4a412aca07 Improve image-filter sample layout/rendering
This tweaks the colors of the filterBounds boxes that are drawn.
It switches DAG layout to be left-to-right instead of top-down.
Visualizes node results/bounds in the local filter space instead of
transforming into the final space.
Improves the source content so that the different branches of the filter
DAG have more meaningful differences.

Change-Id: Icca586dcbcc3156e13f9689ee19af9c03a0ed1eb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228059
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
2019-07-17 21:55:59 +00:00
Michael Ludwig
43c6da2a15 First pass at ImageFilter DAG visualizer sample
Change-Id: I04493af0a6ce1425c4acf68365135722dd3c218b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/227857
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
2019-07-17 20:59:37 +00:00