| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=robertphillips@google.com
Author: bsalomon@google.com
Review URL: https://codereview.chromium.org/608883003
|
|
|
|
|
|
|
|
| |
R=robertphillips@google.com, egdaniel@google.com, joshualitt@google.com, joshualitt@chromium.org
Author: bsalomon@google.com
Review URL: https://codereview.chromium.org/596053002
|
|
|
|
|
|
|
|
|
|
|
| |
the owning bitmap is (already) responsible for knowing the alphatype
BUG=skia:
R=djsollen@google.com
Author: reed@google.com
Review URL: https://codereview.chromium.org/611093002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=jcgregorio@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/614753002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL reduces the amount of information used in the layer cache key:
- the stop value isn't needed since the start value uniquely identifies the layer in the picture.
- only the upper-left 2x2 portion of the CTM should be used as a key for looking up cached layers.
- individual layers can be redraw in different locations so the final offset cannot be a part of the key.
Since this data is no longer stored in the cached layer, but is still required to draw the cached layer, it is now stored in the per-layer information (i.e., HoistedLayer).
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
R=egdaniel@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/609403003
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rebaselining these for now and see if they recur.
R=borenet@google.com
TBR=borenet@google.com
BUG=skia:2956
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/600533003
|
|
|
|
|
|
|
|
| |
R=robertphillips@google.com
Author: bsalomon@google.com
Review URL: https://codereview.chromium.org/586393005
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looks like the name of the directory is "poly" rather than "polyfill".
BUG=None
TEST=None
R=humper@google.com, jcgregorio@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/610003003
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary to build webtry.go as it imports packages from
github.com
BUG=None
TEST=follow the README instructions
R=humper@google.com, jcgregorio@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/601033004
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=robertphillips@google.com
Author: junov@chromium.org
Review URL: https://codereview.chromium.org/612063003
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2795
R=reed@google.com
Author: djsollen@google.com
Review URL: https://codereview.chromium.org/617443002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=junov@chromium.org, reed@google.com, bsalomon@chromium.org
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/600643002
|
|
|
|
|
|
|
|
|
|
|
| |
This saves a bunch of CPU time in DM, and even better, lets us tear it down!
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/612603002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the wording in the DESIGN doc. Currently it says "the only table" as
implying the database has just a single table.
That is not true, the webtry database has four tables: webtry,
workspace, workspacetry and source_images.
BUG=None
TEST=None
R=jcgregorio@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/611763002
|
|
|
|
|
|
|
|
|
|
|
| |
Apply the same memory limit in the Create() function that we do when
deserializing.
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/610723002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=jcgregorio@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/601203002
|
|
|
|
|
|
|
|
|
| |
TBR=
BUG=418381
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/607913007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/609223003/)
Reason for revert:
Re-landing: Chromium-side fix to be landed with the roll (https://codereview.chromium.org/607853003/)
Original issue's description:
> Revert of Fix SkTextBlob offset semantics. (patchset #2 id:20001 of https://codereview.chromium.org/605533002/)
>
> Reason for revert:
> Breaking the Chrome builds with the error:
>
> [14:54:14.317833] ../../skia/ext/pixel_ref_utils.cc:221:16: error: 'drawPosText' marked 'override' but does not override any member functions
> [14:54:14.318022] virtual void drawPosText(const SkDraw& draw,
> [14:54:14.318082] ^
>
> Original issue's description:
> > Fix SkTextBlob offset semantics.
> >
> > Implement proper x/y drawTextBlob() handling by plumbing a
> > drawPosText() offset parameter (to act as an additional glyph pos
> > translation) throughout the device layer.
> >
> > The new offset superceeds the existing constY, with a minor semantic
> > tweak: whereas previous implementations were ignoring constY in 2D
> > positioning mode (scalarsPerGlyph == 2), now the offset is always
> > observed, in all positioning modes. We can do this because existing
> > drawPosText() clients always pass constY == 0 for full positioning mode.
> >
> > R=reed@google.com, jvanverth@google.com, robertphillips@google.com
> >
> > Committed: https://skia.googlesource.com/skia/+/c13bc571d3e61a43b87eb97f0719abd304cafaf2
>
> TBR=jvanverth@google.com,reed@google.com,bsalomon@google.com,fmalita@chromium.org
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://skia.googlesource.com/skia/+/d46b8d2bab7cfba8458432248e1568ac377429e9
R=jvanverth@google.com, reed@google.com, bsalomon@google.com, robertphillips@google.com
TBR=bsalomon@google.com, jvanverth@google.com, reed@google.com, robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/607413003
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL splits the unit test changes out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
For various reasons GrRecordReplaceDraw now needs to take an SkPicture (rather than an SkRecord and a BBH).
R=egdaniel@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/608823002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome's TSAN bots are seeing various races on the bounds of the empty
path ref, and it's a simple fix to just force them on creation. In
fact, we used to do this for this very reason, but for some reason it
looks like I decided it wasn't necessary. Maybe not, but it certainly
doesn't hurt, and it's nice to keep TSAN happy.
Reminder to self: merge this into M39 branch too.
BUG=418299
R=fmalita@chromium.org, robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/603503003
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having the picture contents not actually reside in the 0,0..W,H range wrecks havoc with the layer hoisting. The hoisting works correctly but since the picture don't fulfill their contract the results look incorrect.
This CL just translates the picture's contents to the right so they are within the picture bound.
R=egdaniel@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/594363003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/605533002/)
Reason for revert:
Breaking the Chrome builds with the error:
[14:54:14.317833] ../../skia/ext/pixel_ref_utils.cc:221:16: error: 'drawPosText' marked 'override' but does not override any member functions
[14:54:14.318022] virtual void drawPosText(const SkDraw& draw,
[14:54:14.318082] ^
Original issue's description:
> Fix SkTextBlob offset semantics.
>
> Implement proper x/y drawTextBlob() handling by plumbing a
> drawPosText() offset parameter (to act as an additional glyph pos
> translation) throughout the device layer.
>
> The new offset superceeds the existing constY, with a minor semantic
> tweak: whereas previous implementations were ignoring constY in 2D
> positioning mode (scalarsPerGlyph == 2), now the offset is always
> observed, in all positioning modes. We can do this because existing
> drawPosText() clients always pass constY == 0 for full positioning mode.
>
> R=reed@google.com, jvanverth@google.com, robertphillips@google.com
>
> Committed: https://skia.googlesource.com/skia/+/c13bc571d3e61a43b87eb97f0719abd304cafaf2
R=jvanverth@google.com, reed@google.com, bsalomon@google.com, fmalita@chromium.org
TBR=bsalomon@google.com, fmalita@chromium.org, jvanverth@google.com, reed@google.com
NOTREECHECKS=true
NOTRY=true
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/609223003
|
|
|
|
|
|
|
|
| |
Test needs to be rebaselined on gpu
TBR=bsalomon
Review URL: https://codereview.chromium.org/602203006
|
|
|
|
|
|
|
|
|
| |
BUG=crbug.com/415100
R=bsalomon@google.com, robertphillips@google.com
Author: junov@chromium.org
Review URL: https://codereview.chromium.org/607993002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convenience function requested for Chrome compositor that may have a performance
advantage.
BUG=skia:1017
R=reed@google.com, danakj@chromium.org, vollick@chromium.org
Author: tomhudson@google.com
Review URL: https://codereview.chromium.org/508303005
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=reed@google.com, junov@chromium.org
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/605843002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement proper x/y drawTextBlob() handling by plumbing a
drawPosText() offset parameter (to act as an additional glyph pos
translation) throughout the device layer.
The new offset superceeds the existing constY, with a minor semantic
tweak: whereas previous implementations were ignoring constY in 2D
positioning mode (scalarsPerGlyph == 2), now the offset is always
observed, in all positioning modes. We can do this because existing
drawPosText() clients always pass constY == 0 for full positioning mode.
R=reed@google.com, jvanverth@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/605533002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=reed@google.com, junov@chromium.org
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/599203007
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class.
Besides splitting the two classes, there are no logical changes here and mostly moving code around.
BUG=skia:
R=bsalomon@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/597323002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise changes made to the configuration won't take effect when they
are synced.
BUG=None
TEST=None
R=jcgregorio@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/602293002
|
|
|
|
|
|
|
|
|
|
| |
Automatic commit by the RecreateSKPs bot.
TBR=
Author: borenet@google.com
Review URL: https://codereview.chromium.org/604983003
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Broken in https://skia.googlesource.com/skia/+/9fa60daad4d5f54c0dbe3dbcc7608a8f6d721187.
R=reed@google.com
TBR=reed@google.com
BUG=skia:
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/604873004
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=junov@chromium.org, reed@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/595043002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=junov@chromium.org, reed@google.com, bsalomon@chromium.org
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/608623002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/603263002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fDirtyBits is only used by SkPaint::FlatteningTraits, which in turn was
only used as a smaller, faster format to flatten paints in-memory to dedup
them in the old picture backend.
SkRecord obsoleted all this. Neither flatten()/unflatten() (disk format)
nor FlatteningTraits is used anywhere performance or size matters.
Here I revert the deduping code back to using the disk format for flattened paints.
We stil do have to flatten and unflatten paints while coverting from SkRecord
backend to the old backend, so we can't just delete this all yet, but any
faithful round trip flatten()/unflatten() pair will be fine, however slow.
NOTRY=true
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/604813003
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
Committed: https://skia.googlesource.com/skia/+/432789972c1e1f8a66165c75a250dba1853efa08
R=junov@chromium.org, reed@google.com, bsalomon@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/583453002
|
|
|
|
|
|
|
|
|
|
|
| |
Validation was failing due to an inverted test condition.
BUG=417266
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/596333002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CTFontGetGlyphsForChars puts the glyph id at the index of the lead
surrogate as is documented in comments, but the code is looking at
the index of the trail surrogate.
BUG=skia:2960
R=mtklein@google.com
Author: bungeman@google.com
Review URL: https://codereview.chromium.org/596413002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Canvas (patchset #9 id:160001 of https://codereview.chromium.org/583453002/)
Reason for revert:
Broke ChromiumOS Ozone builder: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Ozone%20Builder/builds/4087/steps/compile/logs/stdio
Reverting to unblock DEPS roll.
Original issue's description:
> SkCanvas::drawImage is the new way for drawing a SkImage to a Canvas
>
> BUG=skia:2947
>
> Committed: https://skia.googlesource.com/skia/+/432789972c1e1f8a66165c75a250dba1853efa08
R=junov@chromium.org, reed@google.com, bsalomon@google.com, piotaixr@chromium.org
TBR=bsalomon@google.com, junov@chromium.org, piotaixr@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2947
Author: borenet@google.com
Review URL: https://codereview.chromium.org/598133002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=bsalomon@google.com, joshualitt@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/599963002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Was looking at performance here (it's the record hotspot) and noticed we
iterate through the grid out of order. This is a tiny little thing, but it's
probably orthogonal to any other performance improvements we'll make in here.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/598933004
|
|
|
|
|
|
|
|
|
|
|
| |
The prior code assumed all layers came from a single picture.
BUG=skia:2315
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/595543002
|
|
|
|
|
|
|
| |
This reverts commit e3d4bf234a04e14b6b0f33e11b3e1132b560c145.
Conflicts:
src/gpu/GrContext.cpp
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't know that anyone but me is using this. Speak up now!
BUG=skia:
NOTREECHECKS=true
R=mtklein@google.com, tfarina@chromium.org
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/599913002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1cea736c3280b6f0553e3eaa598e41370b305b57.
Caused segfaults on all Android devices
R=bsalomon@google.com, djsollen@google.com
TBR=bsalomon, djsollen
NOTRY=true
BUG=skia:
Author: borenet@google.com
Review URL: https://codereview.chromium.org/599493003
|
|
|
|
|
|
|
|
|
|
| |
Automatic commit by the RecreateSKPs bot.
TBR=
Author: borenet@google.com
Review URL: https://codereview.chromium.org/595203002
|
|
|
|
|
|
|
|
|
|
| |
Allow setting skia_egl=1 to build skia against EGL instead of GLX on unix
R=bsalomon@google.com, djsollen@google.com
Author: derekf@osg.samsung.com
Review URL: https://codereview.chromium.org/543363004
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2947
R=junov@chromium.org, reed@google.com, bsalomon@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/583453002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this CL, SkRecord only adjusted the bounds of draw ops for SaveLayers' paints.
That worked fine, but as a final step we intersect the bounds of draw ops with the
bounds of the current clip, essentially undoing all that work.
I think the right fix here is to also adjust the bounds of the clip ops.
BUG=skia:2957, 415468
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/595953002
|