Feature-wise, this removes:
1) BBH support;
2) peephole optimizations;
3) record-time text op specializations;
4) the guarantee that SkPaints are flattened.
This deletes the optimizations GM, which only exists to test the peepholes of
the old backend. SkRecord optimizations are unit tested, and if that ever fails we
can think about adding another GM like this, but they're different enough we'd
want to start from scratch anyway.
We need to keep the code that plays back the specialized text ops around for
a while for compatibility with existing .SKPs that have those ops recorded.
BUG=skia:
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/617953002
In the Sierpinkski test case there are only a few layers appear in the "to be drawn" lists but they those layers get reused a lot of times with different transforms. This CL adds an additional category to allow such layers to be placed in the GrReplacements object without needing to be rendered.
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/)
BUG=skia:2315
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/616023002
Otherwise it will through an error like the following:
2014/09/28 21:22:24 Info: status creating sqlite table for sources:
"table source_images already exists"
2014/09/28 21:22:24 Info: status creating sqlite table for webtry:
"table webtry already exists"
2014/09/28 21:22:24 Info: status creating sqlite table for workspace:
"table workspace already exists"
2014/09/28 21:22:24 Info: status creating sqlite table for workspace
try: "table workspacetry already exists"
To test locally the following was done:
$ ./gyp_skia gyp/webtry.gyp gyp/most.gyp -Dskia_gpu=0
$ ninja -C out/Debug webtry
$ cd experimental/webtry
$ go get -d
$ go build webtry.go
$ ./webtry
$ google-chrome http://localhost:8000
Expected: see no more the above messages.
BUG=None
TEST=see above
R=stephana@google.com, jcgregorio@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/613593002
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
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
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
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
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
