gecko-dev/gfx/layers/RotatedBuffer.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

420 строки
14 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
2012-05-21 15:12:37 +04:00
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef ROTATEDBUFFER_H_
#define ROTATEDBUFFER_H_
#include "gfxTypes.h"
#include <stdint.h> // for uint32_t
#include "mozilla/Assertions.h" // for MOZ_ASSERT, etc
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
#include "mozilla/RefPtr.h" // for RefPtr, already_AddRefed
#include "mozilla/gfx/2D.h" // for DrawTarget, etc
#include "mozilla/gfx/MatrixFwd.h" // for Matrix
#include "mozilla/layers/TextureClient.h" // for TextureClient
#include "mozilla/mozalloc.h" // for operator delete
#include "nsCOMPtr.h" // for already_AddRefed
#include "nsISupportsImpl.h" // for MOZ_COUNT_CTOR, etc
#include "nsRegion.h" // for nsIntRegion
#include "LayersTypes.h"
namespace mozilla {
namespace layers {
class PaintedLayer;
class ContentClient;
// Mixin class for classes which need logic for loaning out a draw target.
// See comments on BorrowDrawTargetForQuadrantUpdate.
class BorrowDrawTarget {
public:
void ReturnDrawTarget(gfx::DrawTarget*& aReturned);
protected:
// The draw target loaned by BorrowDrawTargetForQuadrantUpdate. It should not
// be used, we just keep a reference to ensure it is kept alive and so we can
// correctly restore state when it is returned.
RefPtr<gfx::DrawTarget> mLoanedDrawTarget;
gfx::Matrix mLoanedTransform;
};
/**
* This is a cairo/Thebes surface, but with a literal twist. Scrolling
* causes the layer's visible region to move. We want to keep
* reusing the same surface if the region size hasn't changed, but we don't
* want to keep moving the contents of the surface around in memory. So
* we use a trick.
* Consider just the vertical case, and suppose the buffer is H pixels
* high and we're scrolling down by N pixels. Instead of copying the
* buffer contents up by N pixels, we leave the buffer contents in place,
* and paint content rows H to H+N-1 into rows 0 to N-1 of the buffer.
* Then we can refresh the screen by painting rows N to H-1 of the buffer
* at row 0 on the screen, and then painting rows 0 to N-1 of the buffer
* at row H-N on the screen.
* mBufferRotation.y would be N in this example.
*/
class RotatedBuffer : public BorrowDrawTarget {
public:
Bug 913872 - Take nested enums out of gfxASurface - 1/3 : automatic changes - r=jrmuizel Generated by these regexes: find . -name '*.h' -o -name '*.cpp' -o -name '*.mm' | grep -v '\.hg' | grep -v '^\.\/obj' | xargs sed -i 's/gfx[A-Za-z0-9_]*Surface\:\:[a-z]*\(\(ImageFormat\|SurfaceType\|ContentType\|MemoryLocation\)[0-9A-Za-z_]*\)/gfx\1/g' find . -name '*.h' -o -name '*.cpp' -o -name '*.mm' | grep -v '\.hg' | grep -v '^\.\/obj' | xargs sed -i 's/gfx[A-Za-z0-9_]*Surface\:\:[a-z]*\(\(CONTENT_\|MEMORY_\)[0-9A-Za-z_]*\)/GFX_\1/g' find . -name '*.h' -o -name '*.cpp' -o -name '*.mm' | grep -v '\.hg' | grep -v '^\.\/obj' | xargs sed -i 's/\(^\|[^A-Za-z0-9_]\)\(CONTENT_COLOR\|CONTENT_ALPHA\|CONTENT_COLOR_ALPHA\|CONTENT_SENTINEL\|MEMORY_IN_PROCESS_HEAP\|MEMORY_IN_PROCESS_NONHEAP\|MEMORY_OUT_OF_PROCESS\)\($\|[^A-Za-z0-9_]\)/\1GFX_\2\3/g' find . -name '*.h' -o -name '*.cpp' -o -name '*.mm' | grep -v '\.hg' | grep -v '^\.\/obj' | xargs sed -i 's/\(^\|[^A-Za-z0-9_]\)\(ImageFormatARGB32\|ImageFormatRGB24\|ImageFormatA8\|ImageFormatA1\|ImageFormatRGB16_565\|ImageFormatUnknown\|SurfaceTypeImage\|SurfaceTypePDF\|SurfaceTypePS\|SurfaceTypeXlib\|SurfaceTypeXcb\|SurfaceTypeGlitz\|SurfaceTypeQuartz\|SurfaceTypeWin32\|SurfaceTypeBeOS\|SurfaceTypeDirectFB\|SurfaceTypeSVG\|SurfaceTypeOS2\|SurfaceTypeWin32Printing\|SurfaceTypeQuartzImage\|SurfaceTypeScript\|SurfaceTypeQPainter\|SurfaceTypeRecording\|SurfaceTypeVG\|SurfaceTypeGL\|SurfaceTypeDRM\|SurfaceTypeTee\|SurfaceTypeXML\|SurfaceTypeSkia\|SurfaceTypeSubsurface\|SurfaceTypeD2D\|SurfaceTypeMax\)\($\|[^A-Za-z0-9_]\)/\1gfx\2\3/g'
2013-09-25 00:45:13 +04:00
typedef gfxContentType ContentType;
NS_INLINE_DECL_THREADSAFE_REFCOUNTING(RotatedBuffer)
RotatedBuffer(const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
: mCapture(nullptr),
mBufferRect(aBufferRect),
mBufferRotation(aBufferRotation),
mDidSelfCopy(false) {}
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
RotatedBuffer() : mCapture(nullptr), mDidSelfCopy(false) {}
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
/**
* Initializes the rotated buffer to begin capturing all drawing performed
* on it, to be eventually replayed. Callers must call EndCapture, or
* FlushCapture before the rotated buffer is destroyed.
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 2f63464c1f8ca03992700b33838c4aa56608f872
2018-07-26 19:23:26 +03:00
*/
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
void BeginCapture();
/**
* Finishes a capture and returns it. The capture must be replayed to the
* buffer before it is presented or it will contain invalid contents.
*/
RefPtr<gfx::DrawTargetCapture> EndCapture();
/**
* Returns whether the RotatedBuffer is currently capturing all drawing
* performed on it, to be eventually replayed.
*/
bool IsCapturing() const { return !!mCapture; }
/**
* Draws the contents of this rotated buffer into the specified draw target.
* It is the callers repsonsibility to ensure aTarget is flushed after calling
* this method.
*/
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
void DrawBufferWithRotation(
gfx::DrawTarget* aTarget, float aOpacity = 1.0,
gfx::CompositionOp aOperator = gfx::CompositionOp::OP_OVER,
gfx::SourceSurface* aMask = nullptr,
const gfx::Matrix* aMaskTransform = nullptr) const;
/**
* Complete the drawing operation. The region to draw must have been
* drawn before this is called. The contents of the buffer are drawn
* to aTarget.
*/
void DrawTo(PaintedLayer* aLayer, gfx::DrawTarget* aTarget, float aOpacity,
gfx::CompositionOp aOp, gfx::SourceSurface* aMask,
const gfx::Matrix* aMaskTransform);
/**
* Update the specified region of this rotated buffer with the contents
* of a source rotated buffer.
*/
void UpdateDestinationFrom(const RotatedBuffer& aSource,
const gfx::IntRect& aUpdateRect);
/**
* A draw iterator is used to keep track of which quadrant of a rotated
* buffer and region of that quadrant is being updated.
*/
struct DrawIterator {
friend class RotatedBuffer;
DrawIterator() : mCount(0) {}
nsIntRegion mDrawRegion;
private:
uint32_t mCount;
};
/**
* Get a draw target at the specified resolution for updating |aBounds|,
* which must be contained within a single quadrant.
*
* The result should only be held temporarily by the caller (it will be kept
* alive by this). Once used it should be returned using ReturnDrawTarget.
* BorrowDrawTargetForQuadrantUpdate may not be called more than once without
* first calling ReturnDrawTarget.
*
* ReturnDrawTarget will by default restore the transform on the draw target.
* But it is the callers responsibility to restore the clip.
* The caller should flush the draw target, if necessary.
* If aSetTransform is false, the required transform will be set in
* aOutTransform.
*/
gfx::DrawTarget* BorrowDrawTargetForQuadrantUpdate(
const gfx::IntRect& aBounds, DrawIterator* aIter);
struct Parameters {
Parameters(const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
: mBufferRect(aBufferRect),
mBufferRotation(aBufferRotation),
mDidSelfCopy(false) {}
bool IsRotated() const;
bool RectWrapsBuffer(const gfx::IntRect& aRect) const;
void SetUnrotated();
gfx::IntRect mBufferRect;
gfx::IntPoint mBufferRotation;
bool mDidSelfCopy;
};
/**
* Returns the new buffer parameters for rotating to a
* destination buffer rect.
*/
Parameters AdjustedParameters(const gfx::IntRect& aDestBufferRect) const;
/**
* Unrotates the pixels of the rotated buffer for the specified
* new buffer parameters.
*/
bool UnrotateBufferTo(const Parameters& aParameters);
void SetParameters(const Parameters& aParameters);
/**
* |BufferRect()| is the rect of device pixels that this
* RotatedBuffer covers. That is what DrawBufferWithRotation()
* will paint when it's called.
*/
const gfx::IntRect& BufferRect() const { return mBufferRect; }
const gfx::IntPoint& BufferRotation() const { return mBufferRotation; }
/**
* Overrides the current buffer rect with the specified rect.
* Do not do this unless you know what you're doing.
*/
void SetBufferRect(const gfx::IntRect& aBufferRect) {
mBufferRect = aBufferRect;
}
/**
* Overrides the current buffer rotation with the specified point.
* Do not do this unless you know what you're doing.
*/
void SetBufferRotation(const gfx::IntPoint& aBufferRotation) {
mBufferRotation = aBufferRotation;
}
/**
* Returns whether this buffer did a self copy when adjusting to
* a new buffer rect. This is only used externally for syncing
* rotated buffers.
*/
bool DidSelfCopy() const { return mDidSelfCopy; }
/**
* Clears the self copy flag.
*/
void ClearDidSelfCopy() { mDidSelfCopy = false; }
/**
* Gets the content type for this buffer.
*/
ContentType GetContentType() const;
virtual bool IsLocked() = 0;
virtual bool Lock(OpenMode aMode) = 0;
virtual void Unlock() = 0;
virtual bool HaveBuffer() const = 0;
virtual bool HaveBufferOnWhite() const = 0;
virtual gfx::SurfaceFormat GetFormat() const = 0;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual already_AddRefed<gfx::SourceSurface> GetBufferSource() const {
return GetBufferTarget()->Snapshot();
}
virtual gfx::DrawTarget* GetBufferTarget() const = 0;
virtual TextureClient* GetClient() const { return nullptr; }
virtual TextureClient* GetClientOnWhite() const { return nullptr; }
protected:
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual ~RotatedBuffer() { MOZ_ASSERT(!mCapture); }
enum XSide { LEFT, RIGHT };
enum YSide { TOP, BOTTOM };
gfx::IntRect GetQuadrantRectangle(XSide aXSide, YSide aYSide) const;
gfx::Rect GetSourceRectangle(XSide aXSide, YSide aYSide) const;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
gfx::DrawTarget* GetDrawTarget() const {
if (mCapture) {
return mCapture;
}
return GetBufferTarget();
}
/*
* If aMask is non-null, then it is used as an alpha mask for rendering this
* buffer. aMaskTransform must be non-null if aMask is non-null, and is used
* to adjust the coordinate space of the mask.
*/
void DrawBufferQuadrant(gfx::DrawTarget* aTarget, XSide aXSide, YSide aYSide,
float aOpacity, gfx::CompositionOp aOperator,
gfx::SourceSurface* aMask,
const gfx::Matrix* aMaskTransform) const;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
RefPtr<gfx::DrawTargetCapture> mCapture;
/** The area of the PaintedLayer that is covered by the buffer as a whole */
gfx::IntRect mBufferRect;
/**
* The x and y rotation of the buffer. Conceptually the buffer
* has its origin translated to mBufferRect.TopLeft() - mBufferRotation,
* is tiled to fill the plane, and the result is clipped to mBufferRect.
* So the pixel at mBufferRotation within the buffer is what gets painted at
* mBufferRect.TopLeft().
* This is "rotation" in the sense of rotating items in a linear buffer,
* where items falling off the end of the buffer are returned to the
* buffer at the other end, not 2D rotation!
*/
gfx::IntPoint mBufferRotation;
/**
* When this is true it means that all pixels have moved inside the buffer.
* It's not possible to sync with another buffer without a full copy.
*/
bool mDidSelfCopy;
};
/**
* RemoteRotatedBuffer is a rotated buffer that is backed by texture
* clients. Before you use this class you must successfully lock it with
* an appropriate open mode, and then also unlock it when you're finished.
* RemoteRotatedBuffer is used by ContentClientSingleBuffered and
* ContentClientDoubleBuffered for the OMTC code path.
*/
class RemoteRotatedBuffer : public RotatedBuffer {
public:
RemoteRotatedBuffer(TextureClient* aClient, TextureClient* aClientOnWhite,
const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
: RotatedBuffer(aBufferRect, aBufferRotation),
mClient(aClient),
mClientOnWhite(aClientOnWhite) {}
virtual bool IsLocked() override;
virtual bool Lock(OpenMode aMode) override;
virtual void Unlock() override;
virtual bool HaveBuffer() const override { return !!mClient; }
virtual bool HaveBufferOnWhite() const override { return !!mClientOnWhite; }
virtual gfx::SurfaceFormat GetFormat() const override;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual gfx::DrawTarget* GetBufferTarget() const override;
virtual TextureClient* GetClient() const override { return mClient; }
virtual TextureClient* GetClientOnWhite() const override {
return mClientOnWhite;
}
void SyncWithObject(SyncObjectClient* aSyncObject);
void Clear();
private:
RemoteRotatedBuffer(TextureClient* aClient, TextureClient* aClientOnWhite,
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
gfx::DrawTarget* aTarget, gfx::DrawTarget* aTargetOnWhite,
gfx::DrawTarget* aTargetDual,
const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
: RotatedBuffer(aBufferRect, aBufferRotation),
mClient(aClient),
mClientOnWhite(aClientOnWhite),
mTarget(aTarget),
mTargetOnWhite(aTargetOnWhite),
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
mTargetDual(aTargetDual) {}
RefPtr<TextureClient> mClient;
RefPtr<TextureClient> mClientOnWhite;
RefPtr<gfx::DrawTarget> mTarget;
RefPtr<gfx::DrawTarget> mTargetOnWhite;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
RefPtr<gfx::DrawTarget> mTargetDual;
};
/**
* DrawTargetRotatedBuffer is a rotated buffer that is backed by draw targets,
* and is used by ContentClientBasic for the on-mtc code path.
*/
class DrawTargetRotatedBuffer : public RotatedBuffer {
public:
DrawTargetRotatedBuffer(gfx::DrawTarget* aTarget,
gfx::DrawTarget* aTargetOnWhite,
const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
: RotatedBuffer(aBufferRect, aBufferRotation),
mTarget(aTarget),
mTargetOnWhite(aTargetOnWhite) {
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
if (mTargetOnWhite) {
mTargetDual = gfx::Factory::CreateDualDrawTarget(mTarget, mTargetOnWhite);
} else {
mTargetDual = mTarget;
}
}
virtual bool IsLocked() override { return false; }
virtual bool Lock(OpenMode aMode) override { return true; }
virtual void Unlock() override {}
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual bool HaveBuffer() const override { return !!mTargetDual; }
virtual bool HaveBufferOnWhite() const override { return !!mTargetOnWhite; }
virtual gfx::SurfaceFormat GetFormat() const override;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual gfx::DrawTarget* GetBufferTarget() const override;
private:
RefPtr<gfx::DrawTarget> mTarget;
RefPtr<gfx::DrawTarget> mTargetOnWhite;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
RefPtr<gfx::DrawTarget> mTargetDual;
};
/**
* SourceRotatedBuffer is a rotated buffer that is backed by source surfaces,
* and may only be used to draw into other buffers or be read directly.
*/
class SourceRotatedBuffer : public RotatedBuffer {
public:
SourceRotatedBuffer(gfx::SourceSurface* aSource,
gfx::SourceSurface* aSourceOnWhite,
const gfx::IntRect& aBufferRect,
const gfx::IntPoint& aBufferRotation)
: RotatedBuffer(aBufferRect, aBufferRotation),
mSource(aSource),
mSourceOnWhite(aSourceOnWhite) {
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
mSourceDual =
gfx::Factory::CreateDualSourceSurface(mSource, mSourceOnWhite);
}
virtual bool IsLocked() override { return false; }
virtual bool Lock(OpenMode aMode) override { return false; }
virtual void Unlock() override {}
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual already_AddRefed<gfx::SourceSurface> GetBufferSource() const override;
virtual gfx::SurfaceFormat GetFormat() const override;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual bool HaveBuffer() const override { return !!mSourceDual; }
virtual bool HaveBufferOnWhite() const override { return !!mSourceOnWhite; }
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
virtual gfx::DrawTarget* GetBufferTarget() const override { return nullptr; }
private:
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
RefPtr<gfx::SourceSurface> mSource;
RefPtr<gfx::SourceSurface> mSourceOnWhite;
Bug 1478815 part 8 - Remove buffer operations for ContentClient. r=nical This commit moves ContentClient from creating a CapturedBufferState for buffer operations, to performing all of those operations on the DrawTarget(Capture). Creating a DrawTargetCapture is now performed by the RotatedBuffer when we BeginPaint, all operations are performed on this capture, and then it's returned to the ClientPaintedLayer as a PaintTask. This commit is an involved refactoring of ContentClient and RotatedBuffer to get this all to work. Here are the major parts: 1. RotatedBuffer is refactored to always perform operations on a single DrawTarget, which may be a single DT, dual DT, or capture. 2. RotatedBuffer adds BeginCapture and EndCapture methods to switch which DT is used in operations 3. ContentClient uses the RB capture methods when we are async painting 4. CC::BeginPaint is refactored to only perform capturing on a single RotatedBuffer. This is because we can't have the output of one PaintTask be the input of a different PaintTask due to the design of the Snapshot API. a. This can occur, today, by doing a FinalizeFrame only to later fail to Unrotate the buffer, causing a new RB to be created and painted into b. The previous PaintThread code worked because it used the buffer operations which didn't use Snapshot's c. This is fixed by not doing FinalizeFrame on a buffer if we realize we cannot unrotate it, and switching to initializing a buffer using the front buffer which should be up to date. d. I don't like touching this code, but it passes reftests, might be a performance improvement, and I've tested it on known regressions from the last time I messed up this code. 5. CC::PrepareForPaint is inlined into BeginPaint because dual draw targets can be cleared correctly from a previous commit 6. The code paths in ClientPaintedLayer are unified because we no longer need to special case this beyond setting the correct ContentClient flag. 7. CapturedPaintState and CapturedBufferState are removed in favor of PaintTask. Additionally EndLayer is no longer needed as all quadrants of a rotated buffer are in the same capture, so we don't need special case flushing code. MozReview-Commit-ID: 9UI40dwran --HG-- extra : rebase_source : 809d9816970648468de972c30b0c230c2f21e27b extra : source : 405ad351821813333c0e989b93e2aeb49ba8552c
2018-07-26 19:23:26 +03:00
RefPtr<gfx::SourceSurface> mSourceDual;
};
} // namespace layers
} // namespace mozilla
#endif /* ROTATEDBUFFER_H_ */