aboutsummaryrefslogtreecommitdiffhomepage
path: root/gm/verylargebitmap.cpp
Commit message (Collapse)AuthorAge
* remove unused GM flagsGravatar mtklein2015-01-23
| | | | | | | | | | Depends on https://codereview.chromium.org/873753002/ Thumbs up to CLion for refactoring this for me. BUG=skia: Review URL: https://codereview.chromium.org/867963004
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | This fixes every case where virtual and SK_OVERRIDE were on the same line, which should be the bulk of cases. We'll have to manually clean up the rest over time unless I level up in regexes. for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end BUG=skia: Review URL: https://codereview.chromium.org/806653007
* Add always-threaded SkRecord quilt tests.Gravatar mtklein2014-07-07
| | | | | | | | | | | | | | | | | | | | | 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
* Turn on quilt mode in DM.Gravatar commit-bot@chromium.org2014-04-30
| | | | | | | | | | | | | | | | | | - Rename TileGrid -> Quilt to avoid the name overload. - Tag all failing GMs with kSkipTiled_Flag. You may be wondering, do any GMs pass? Yes, some do! And that trends towards all of them as we increase --quiltTile. Two GMs only fail in --quilt mode in 565. Otherwise all GMs which fail are skipped, and those which don't fail aren't. (The 8888 variants of those two GMs are skipped even though they pass.) BUG=skia:2477 R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/256373002 git-svn-id: http://skia.googlecode.com/svn/trunk@14457 2bbb7eff-a529-9590-31e7-b0007b416f81
* gather GM tests which are disabled on AndroidGravatar commit-bot@chromium.org2014-03-24
| | | | | | | | | | | BUG=skia:2326 R=borenet@google.com, djsollen@google.com Author: epoger@google.com Review URL: https://codereview.chromium.org/208313014 git-svn-id: http://skia.googlecode.com/svn/trunk@13922 2bbb7eff-a529-9590-31e7-b0007b416f81
* add legacy/helper allocN32Pixels, and convert gm to use itGravatar reed@google.com2014-01-25
| | | | | | | | | | | | This is an intermediate api, but might help us quickly get to a point where no one is creating bitmaps in a 2-step process (setConfig + alloc). BUG=skia: R=halcanary@google.com Review URL: https://codereview.chromium.org/140593005 git-svn-id: http://skia.googlecode.com/svn/trunk@13182 2bbb7eff-a529-9590-31e7-b0007b416f81
* Exclude verylargebitmap test from replay modes on windows.Gravatar commit-bot@chromium.org2013-10-30
| | | | | | | | | | | BUG=skia:1756 R=epoger@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/52903003 git-svn-id: http://skia.googlecode.com/svn/trunk@12030 2bbb7eff-a529-9590-31e7-b0007b416f81
* Reduce bitmap sizes in verylargebitmap GM to not crash on windowsGravatar bsalomon@google.com2013-10-24
| | | | | | | | R=scroggo@google.com Review URL: https://codereview.chromium.org/39033005 git-svn-id: http://skia.googlecode.com/svn/trunk@11954 2bbb7eff-a529-9590-31e7-b0007b416f81
* Tile large bitmaps that are clipped.Gravatar bsalomon@google.com2013-10-24
| | | | | | | | R=robertphillips@google.com Review URL: https://codereview.chromium.org/31033002 git-svn-id: http://skia.googlecode.com/svn/trunk@11951 2bbb7eff-a529-9590-31e7-b0007b416f81
* Reduce verylargebitmap GM's memory footprintGravatar robertphillips@google.com2013-07-15
| | | | | | | | https://codereview.chromium.org/19217002/ git-svn-id: http://skia.googlecode.com/svn/trunk@10083 2bbb7eff-a529-9590-31e7-b0007b416f81
* Result of running tools/sanitize_source_files.py (which was added in ↵Gravatar rmistry@google.com2012-08-23
| | | | | | | | | https://codereview.appspot.com/6465078/) This CL is part III of IV (I broke down the 1280 files into 4 CLs). Review URL: https://codereview.appspot.com/6475053 git-svn-id: http://skia.googlecode.com/svn/trunk@5264 2bbb7eff-a529-9590-31e7-b0007b416f81
* Remove verylargebitmap gm on AndroidGravatar borenet@google.com2012-08-07
| | | | | | | We can't allocate that much memory on Android Review URL: https://codereview.appspot.com/6460054 git-svn-id: http://skia.googlecode.com/svn/trunk@4973 2bbb7eff-a529-9590-31e7-b0007b416f81
* add gm for very large bitmaps (>32K >64K)Gravatar reed@google.com2012-08-07
raster expected to fail when scaling >64K (for now) git-svn-id: http://skia.googlecode.com/svn/trunk@4967 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 05:57:07 +0000