Even if we cannot reuse the back buffer, we still use it to initialize the new back buffer.
The correct condition for detecting changes to buffer mode should only care if there is a
buffer, not if we decided to reuse it.
If the buffer mode has changed to component alpha, we need to invalidate and repaint everything
because we won't be able to copy over content to the new buffer correctly.
I believe this is a regression from the refactoring that created this function from
RotatedContentBuffer::BeginPaint.
MozReview-Commit-ID: H9G7GxqekLt
--HG--
extra : rebase_source : afb3321694ce3f1b54ad4dce28b4a7c7c7b47904
extra : amend_source : fdef1994514fcc9b9f2e952767a785841e9ddda0
extra : histedit_source : 3e8324255f516094c242ab3ec0688d2285c85a99
Add a new TextureClientData type, AndroidNativeWindowTextureData,
backed by a SurfaceTexture in single-buffer mode. It uses the
NativeWindow API, which provides producer-side access to the buffer.
This provides a DrawTarget which can be used to paint directly in to
the SurfaceTexture, which can then be composited using a SurfaceTextureHost.
Due to API restrictions it is not possible to read from a NativeWindow
while the corresponding SurfaceTexture has ownership of the
buffer. TiledContentClient now handles that by painting the additional
region that it cannot copy from the front buffer, if required.
MozReview-Commit-ID: 1NZq6MQqwFq
--HG--
extra : rebase_source : 9d1db721d4892f3df033d43127489a85421e8863
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "// \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
####
old="// \* This Source Code Form is subject to the terms of the Mozilla Public"
new=" \* This Source Code Form is subject to the terms of the Mozilla Public"
sed -i s%"^$old"%"$new"% $1
####
MozReview-Commit-ID: Ihx0EAOkT2g
--HG--
extra : rebase_source : 4dc97f234495e3ec1f4904e91d43d00fd3810626
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r " \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1=" \* This Source Code Form is subject to the terms of the Mozilla Public"
line2=" \* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3=" \* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Strip off 1 space at beginning:
sed -i s%"^ $line1"%"$line1"% $1
sed -i s%"^ $line2"%"$line2"% $1
sed -i s%"^ $line3"%"$line3"% $1
###
MozReview-Commit-ID: EwCjyajgY4W
--HG--
extra : rebase_source : c61ca17ba556290d1f27af0a0c84e2ccc5371a36
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
This patch was mostly[1] automatically generated. I found the files to be fixed
in this patch with the following command:
grep -r "C++; indent-tabs-mode:" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
old="/\* -\*- Mode: C++; indent-tabs-mode: nil; c-basic-offset: 4 -\*- \*/"
new="/\* -\*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -\*- \*/"
sed -i s%"^$old"%"$new"% $1
###
[1] NOTE: Nearly all of these files use 2-space indentation, so it's correct
(from a consistency perspective and a reflecting-reality perspective) that
we're reducing their "c-basic-offset: 4" down to "c-basic-offset: 2" here. The
one exception is nsDeviceContext.h, which *does* actually use 4-space
indentation right now -- so I'm leaving that file with "c-basic-offset: 4" in
its mode line. This manual change (reverting 1 character from the automated
process) is the only piece of this patch that isn't automated.
MozReview-Commit-ID: L4MbyeYSbfY
--HG--
extra : rebase_source : 8ddbe422471bfd8b0060e96fb1c8cd062f10f290
This patch doesn't modify the mode lines at all -- it just swaps their order,
and makes each one its own C++ comment, separate from the MPL boilerplate
comment.
MozReview-Commit-ID: BEZJVj2sMuK
--HG--
extra : rebase_source : 9e0946c8a8d0b67c11b5932b9d1e51e0e6e8ebef
The earlier patches in this bug were written before we had
sophisticated binding generation so the types didn't match very well.
This fixes all of that.
MozReview-Commit-ID: DpcblpB8vxW
This changes the serialization format a little bit.
We now have an index at the end of the blob. This
is currently used to store a list of the used font keys.
In the future we'll add rects and can use it for invalidation.
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
