| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/563723005
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/560453002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ex. dm --match patch -w bad --key arch x86 gpu nvidia model z620 --properties git_hash abcd build_number 20 ->
{
"build_number" : "20",
"git_hash" : "abcd",
"key" : {
"arch" : "x86",
"gpu" : "nvidia",
"model" : "z620"
},
"results" : [
{
"key" : {
"config" : "565",
"name" : "ninepatch-stretch"
},
"md5" : "f78cfafcbabaf815f3dfcf61fb59acc7",
"options" : {
"source_type" : "GM"
}
},
{
"key" : {
"config" : "8888",
"name" : "ninepatch-stretch"
},
"md5" : "3e8a42f35a1e76f00caa191e6310d789",
"options" : {
"source_type" : "GM"
}
},
...
This breaks -r, but that's okay. Going to follow up this CL with one that removes that entirely.
BUG=skia:
R=stephana@google.com, jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/551873003
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's getting tricky to coordinate changes to output for bots with -r,
and -r is not widely used. The suggested alternative is to run skdiff.
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/553583004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has the nice property of being able to double-check hashes after the fact.
mtklein@mtklein ~/skia (hash-png)> md5sum bad/8888/3x3bitmaprect.png
deede70ab2f34067d461fb4a93332d4c bad/8888/3x3bitmaprect.png
mtklein@mtklein ~/skia (hash-png)> grep 3x3bitmaprect_8888 bad/dm.json
"3x3bitmaprect_8888" : "deede70ab2f34067d461fb4a93332d4c",
I have checked that no two premultiplied colors map to the same unpremultiplied
color (math nerds: unpremultiplication is injective), so a change in
premultiplied SkBitmap will always imply a change in the encoded
unpremultiplied .png. This means, it's safe to hash .pngs; we won't miss
subtle changes.
BUG=skia:
R=jcgregorio@google.com, stephana@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/549203003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No diff in dm.json output.
Here's what we get when --nameByHash is on:
mtklein@mtklein ~/skia (dm)> ls bad4/
0077fefedcee39feae9d12751853758b.png 431921de1607b4e1ae6864cc684d9b8e.png 8a3e17eba9302498700a703bb286d1ef.png c6448cb266f5e0b8d02b512ad484a9ad.png
01b0dcd515e846ea3b7f3b4c68120943.png 4372eb0fce0b0bcf5a582c502f90ecef.png 8a6acdd96cf6915fa01a9cea6d6291b0.png c6db4e2c9860b900130af429373eafaa.png
02974ab0efa7aa325b3bf22515b33899.png 43bddc2e255a3501ce2728544b1d409d.png 8aa8763d11afd397c2768e54d5599181.png c716a9a53513a16e0572c67863e3be08.png
02b7b9e5e95e69f89b6cec9c4539d972.png 43cf7adda66b3719e4abd19e92dda55e.png 8ade6bb4c9e2244e0dbd9436cf6e2132.png c854bb6dd105644a71d0219025409039.png
02d29dbfd29260f9318fcd6177c6ba7b.png 4423958139a2b64185583dacb7379b13.png 8b039171593685112a9454879f40a965.png c863ac2394e519690c57e1392b14b19f.png
...
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/550283002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/549183002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DM's striking off into its own JSON world. This gets strawman implementations
in place for writing and reading a JSON file mapping test name to hashes.
For what it's worth, I basically want to change _all_ these pieces,
- MD5 is slow and we can replace it with something faster,
- JSON schema needs room to grow more data,
- it'd be nice to hash once instead of twice when reading and writing,
- this code wants lots of refactoring,
but this gives us a starting platform to work on these bits at our leisure.
E.x. file for now:
mtklein@mtklein ~/skia (dm)> cat good/dm.json
{
"3x3bitmaprect_565" : "fc70d985fbfbe70e3a3c9dc626d4f5bc",
"3x3bitmaprect_8888" : "df1591dde35907399734ea19feb76663",
"3x3bitmaprect_gpu" : "df1591dde35907399734ea19feb76663",
"aaclip_565" : "1862798689b838a7ab0dc0652b9ace3a",
"aaclip_8888" : "47bb314329f0ce243f1d83fd583decb7",
"aaclip_gpu" : "75f72412d0ef4815770202d297246e7d",
...
BUG=skia:
R=jcgregorio@google.com, stephana@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/546873002
|
|
|
|
|
|
|
|
| |
R=reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/540963002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
|
|
|
|
|
|
|
|
|
|
| |
This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect.
R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/513983002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're not testing it to the same degree we do RTree and TileGrid. Any changes
we'll make to BBH APIs become 33% easier without it. If find we want it again,
we can always resurrect it.
BUG=skia:1021,skia:2834
R=robertphillips@google.com, mtklein@google.com
TBR=reed
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/500373005
|
|
|
|
|
|
|
|
| |
R=mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/502193002
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/492023002
|
|
|
|
|
|
|
|
|
|
|
| |
Everyone used MB, so update the API to just return that.
BUG=skia:
R=halcanary@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/483323002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only seem to need to sort with SkQuadTree, which is not actively used by
client code. So it's really just wasted work. SkQuadTree is interesting, but
I'd rather disable it than slow down the production code path.
BUG=skia:2834
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/471063004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we've added "angle" to the default list of configs we've been running
kNative_GLContextType tests twice in DM, once for the real native, once for
angle. This pointlessly doubles the GPU critical path in DM. Whoops.
NOTREECHECKS=true
BUG=skia:
R=bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/471063002
|
|
|
|
|
|
|
|
| |
R=caryclark@google.com, mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/468963002
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the need to assume the void* are SkPictureStateTree::Data*.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/466503002
|
|
|
|
|
|
|
|
|
|
| |
Committed: https://skia.googlesource.com/skia/+/6274baae7fe82ce6481da367687aa6168356e1e1
R=mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/448993003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now this only creates a degenerate bounding box hierarchy where all ops
just have maximal bounds. I will flesh out FillBounds in future CL(s).
Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even
looked at the diffs yet---so I've disabled those test modes for now. RTree
seems fine, so that'll at least get us coverage for all this new plumbing.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/454123003
|
|
|
|
|
|
|
|
|
|
|
| |
CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot
BUG=skia:
R=mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/452633002
|
|
|
|
|
|
|
|
|
|
|
|
| |
- limit to maximum 1000x1000 viewport like in bench_pictures and nanobench
- use lazy bitmap decoding when reading the pictures from disk
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/448263002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://codereview.chromium.org/448993003/)
Reason for revert:
Reverting due to breaking iOS bots.
Original issue's description:
> Process Statistics header, add max RSS to render_pdfs
>
> Committed: https://skia.googlesource.com/skia/+/6274baae7fe82ce6481da367687aa6168356e1e1
R=mtklein@google.com, halcanary@google.com
TBR=halcanary@google.com, mtklein@google.com
NOTREECHECKS=true
NOTRY=true
Author: bungeman@google.com
Review URL: https://codereview.chromium.org/448243003
|
|
|
|
|
|
|
|
| |
R=mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/448993003
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
NOTREECHECKS=true
R=halcanary@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/445963002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Must be getting the path ops tests going early helps?
On my desktop,
Release: 50s -> 24s
Debug: 62s -> 40s
BUG=skia:
R=bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/435423003
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to help debug http://skbug.com/2793
BUG=skia:2793
R=halcanary@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/433403005
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to replace bench_pictures.
CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Release-iOS-Trybot
BUG=skia:
R=bsalomon@google.com, jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/425393004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow GM results to be compared across machines and platforms by
standardizing the fonts used by all tests.
This adds runtime flags to DM to use either the system font context (the
default), the fonts in the resources directory ( --resourceFonts ) or a set
of canonical paths generated from the fonts ( --portableFonts ).
This CL should leave the current DM results unchanged by default.
If the portable font data or resource font is missing when DM is run, it
falls back to using the system font context.
The create_test_font tool generates the paths and metrics read by DM
with the --portableFonts flag set, and generates the font substitution
tables read by DM with the --resourceFonts flag set.
If DM is run in SkDebug mode with the --reportUsedChars flag set, it
generates the corresponding data compiled into the create_test_font tool.
All GM tests set their typeface information by calling either
sk_tool_utils::set_portable_typeface or
sk_tool_utils::portable_typeface .
(The former takes the paint, the latter returns a SkTypeface.) These calls
can be removed in the future when the Font Manager can be superceded.
BUG=skia:2687
R=mtklein@google.com
Review URL: https://codereview.chromium.org/407183003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly for brevity and matches better with Python:
Python | Old C++ | New C++
os.path.join | SkOSPath::SkPathJoin | SkOSPath::Join
os.path.basename | SkOSPath::SkBasename | SkOSPath::Basename
BUG=None
TEST=make all
R=mtklein@google.com, bsalomon@google.com
Author: tfarina@chromium.org
Review URL: https://codereview.chromium.org/428443002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename GrContext::contextDestroyed to GrContext::abandonContext.
Remove GrContext::resetContext.
R=robertphillips@google.com
Author: bsalomon@google.com
Review URL: https://codereview.chromium.org/422903002
|
|
|
|
|
|
|
|
| |
R=bungeman@google.com, mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/421713002
|
|
|
|
|
|
|
|
| |
R=bungeman@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/416333007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Share command flags between dm and unit tests.
Also, allow dm's core to be included by itself and iOSShell.
Command line flags that are the same (or nearly the same) in DM
and in skia_tests have been moved to common_flags. Authors,
please check to see that the shared common flag is correct for
the tool.
For iOS, the 'tool_main' entry point has a wrapper to allow multiple
tools to be statically linked in the iOSShell.
Since SkCommandLineFlags::Parse can only be called once, these calls
are disabled in the IOS build.
Since the iOS app directory is dynamically assigned a name, use '@' to
select it. (This is the same convention chosen by the Mobile Harness
iOS file system utilities.)
Move the heart of dm.gyp into dm.gypi so that it can be included by
itself and iOSShell.gyp.
Add tools/flags/SkCommonFlags.* to define and declare common
command line flags.
Add support for dm to iOSShell.
BUG=skia:
R=scroggo@google.com, mtklein@google.com, jvanverth@google.com, bsalomon@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/389653004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://codereview.chromium.org/402663003/)
Reason for revert:
we have to go deeper
Original issue's description:
> Revert of Revert of Force DM rebuild. (https://codereview.chromium.org/399123002/)
>
> Reason for revert:
> jkl;
>
> Original issue's description:
> > Revert of Force DM rebuild. (https://codereview.chromium.org/400723002/)
> >
> > Reason for revert:
> > asdf
> >
> > Original issue's description:
> > > Force DM rebuild.
> > >
> > > BUG=skia:
> > >
> > > Committed: https://skia.googlesource.com/skia/+/8a10de1
> >
> > TBR=mtklein@chromium.org
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=skia:
> >
> > Committed: https://skia.googlesource.com/skia/+/f42e08c12533f2a165bc08451f5ab5dd1363618b
>
> TBR=mtklein@chromium.org
> NOTREECHECKS=true
> NOTRY=true
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/41f30cd87ece55971b17e4a59873cf31100ee1a0
R=mtklein@chromium.org
TBR=mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/397293004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://codereview.chromium.org/399123002/)
Reason for revert:
jkl;
Original issue's description:
> Revert of Force DM rebuild. (https://codereview.chromium.org/400723002/)
>
> Reason for revert:
> asdf
>
> Original issue's description:
> > Force DM rebuild.
> >
> > BUG=skia:
> >
> > Committed: https://skia.googlesource.com/skia/+/8a10de1
>
> TBR=mtklein@chromium.org
> NOTREECHECKS=true
> NOTRY=true
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/f42e08c12533f2a165bc08451f5ab5dd1363618b
R=mtklein@chromium.org
TBR=mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/402663003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reason for revert:
asdf
Original issue's description:
> Force DM rebuild.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8a10de1
R=mtklein@chromium.org
TBR=mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/399123002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/400723002
|
|
|
|
|
|
|
|
|
|
|
| |
This idea turned out to be more redundant than useful.
BUG=skia:
R=mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/399463003
|
|
|
|
|
|
|
|
| |
This is for consistency with bench/nanobench/GM. Haven't seen it make a difference.
BUG=skia:
Review URL: https://codereview.chromium.org/397743004
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Defaulting to true to be conservative for now.
BUG=skia:
NOTREECHECKS=true
R=mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/398483005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replay isn't that helpful of a test any more now that we have the more
stringent Quilt tests. Quilt was missing bounding box hierarchies, though,
while Replay was sort of testing RTree (pointlessly, as it was drawing without
any clip). Now Quilt does everything, testing RTree, QuadTree, and TileGrid.
Quilt mode now falls back to drawing all at once (i.e. Replay) for GMs that
don't tile perfectly. Still a TODO to make this check more flexible than exact
pixel matches.
Two GMs fail when using a BBH:
- imageresizetiled
- resizeimagefilter
We think we're not adjusting the bounds of save layers by their paint.
This is probably a bug, but one to be fixed separately from adding new tests.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/377373003
|
|
|
|
|
|
|
|
|
|
|
| |
This required the same SkBitmap copying that we added today to SkRecord.
BUG=skia:
R=reed@android.com, robertphillips@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/375703002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we're drawing tiles threaded like implside painting, remove the checks
that those lock counts are balanced. They're just not right for anyone anymore.
SkBitmaps themselves are not threadsafe (even const ones), so shallow copy them
on playback of an SkRecord. (The underlying SkPixelRefs are threadsafe.)
Simplify quilt drawing by using SkBitmap::extractSubset. No need for locking.
Bump up to 256x256 tiles. 16x16 tiles just murders performance (way too much
contention). This has the nice side effect of letting us enable a bunch more
GMs for quilt mode; they drew wrong with small tiles but exactly right with large.
BUG=171776
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371023005
|
|
|
|
|
|
|
|
|
|
|
| |
Default off for now. Something to work toward.
BUG=skia:
R=robertphillips@google.com, tomhudson@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/360793002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support using OpenGL ES context on desktop for unix and Android platforms. This
is mainly useful in development.
Add --gpuAPI flag to gm, dm, bench, bench_pictures and render_pictures. The
possible parameters for the flag are "gl" and "gles".
R=bsalomon@google.com, mtklein@google.com, robertphillips@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/319043005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome will need -DSK_SUPPORT_LEGACY_PICTURE_CLONE.
This removes the modes from our tools that use clone(). No
bots run these. DM used clone() in a way that we can just
share the picture now.
I plan to bring back the ability to test multithreaded
picture rendering soon.
BUG=skia:2378
R=robertphillips@google.com, mtklein@google.com, bsalomon@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/338633011
|