| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Review URL: https://codereview.chromium.org/1824983003
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Called by SkRecordOptimize(), this moves all the NoOps to the end and
slices them off.
This implementation with std::remove_if() is linear and doesn't malloc.
No diffs: https://gold.skia.org/search2?issue=1461663003&unt=true&query=source_type%3Dgm&master=false
BUG=skia:
Review URL: https://codereview.chromium.org/1461663003
|
| |
|
|
|
|
|
|
| |
also, (C)
BUG=skia:
Review URL: https://codereview.chromium.org/1300163002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an SkRecord has more than kInlineRecords ops in it (today, 5 or more), the
current logic undercounts the bytes used by the SkRecord by sizeof(Record) *
kInlineRecords, i.e. 32 bytes. This isn't a huge deal... by the time you've
recorded 5 ops, we're typically up around 1KB anyway, and it's only ever off by
that constant 32 bytes, so somewhere between 3% to 0% error as the picture grows.
But now that I've noticed, we might as well fix it. Basically, this is a
reminder that the inline space used to store those first kInlineRecords ops
goes to waste once we pass that threshold. In contrast, fInlineAlloc, the
space we preallocate for the SkVarAlloc, never goes to waste. It always holds
the first few ops' data even when we grow past it.
BUG=skia:
Review URL: https://codereview.chromium.org/1081433002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
Review URL: https://codereview.chromium.org/1061783002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/1061783002/)
Reason for revert:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug/builds/149/steps/dm/logs/stdio
Original issue's description:
> Rearrange SkRecord with small N in mind
>
> This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
>
> picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
>
> I don't see any significant effect on large picture recording times from our .skps.
>
> BUG=chromium:470553
>
> Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
TBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1068383003
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1061783002
|
|
|
Looks like a noop-to-minor-win:
tabl_sahadan.skp 94.9us -> 98.6us 1x
desk_jsfiddlebigcar.skp 38.9us -> 39.7us 1x
desk_silkfinance.skp 78us -> 78.9us 1x
desk_jsfiddlehumperclip.skp 43.8us -> 44.3us 1x
desk_sfgate.skp 547us -> 548us 1x
tabl_gmail.skp 19.9us -> 19.8us 1x
tabl_worldjournal.skp 230us -> 229us 1x
desk_css3gradients.skp 248us -> 247us 1x
tabl_cnn.skp 205us -> 203us 0.99x
desk_linkedin.skp 342us -> 340us 0.99x
desk_wowwiki.skp 1.63ms -> 1.62ms 0.99x
tabl_cnet.skp 142us -> 141us 0.99x
desk_pokemonwiki.skp 9.76ms -> 9.67ms 0.99x
desk_espn.skp 267us -> 264us 0.99x
desk_youtube.skp 576us -> 570us 0.99x
tabl_pravda.skp 238us -> 235us 0.99x
tabl_ukwsj.skp 566us -> 560us 0.99x
tabl_engadget.skp 630us -> 622us 0.99x
desk_googlespreadsheetdashed.skp 1.66ms -> 1.64ms 0.99x
desk_mobilenews.skp 486us -> 480us 0.99x
tabl_googlecalendar.skp 211us -> 208us 0.99x
desk_samoasvg.skp 740us -> 730us 0.99x
desk_gws.skp 187us -> 184us 0.99x
desk_ebay.skp 234us -> 230us 0.99x
desk_mapsvg.skp 1.6ms -> 1.58ms 0.98x
tabl_nytimes.skp 130us -> 128us 0.98x
tabl_googleblog.skp 305us -> 300us 0.98x
desk_fontwipe.skp 40.3us -> 39.6us 0.98x
desk_tigersvg.skp 189us -> 186us 0.98x
tabl_androidpolice.skp 662us -> 650us 0.98x
desk_wordpress.skp 824us -> 809us 0.98x
tabl_mlb.skp 338us -> 331us 0.98x
tabl_culturalsolutions.skp 390us -> 382us 0.98x
desk_baidu.skp 213us -> 208us 0.98x
tabl_gspro.skp 72.9us -> 71.1us 0.97x
tabl_nofolo.skp 74us -> 71.9us 0.97x
desk_yahooanswers.skp 173us -> 168us 0.97x
tabl_frantzen.skp 57.3us -> 55.6us 0.97x
desk_chalkboard.skp 891us -> 865us 0.97x
desk_pinterest.skp 154us -> 149us 0.97x
desk_blogger.skp 537us -> 519us 0.97x
tabl_hsfi.skp 10.1us -> 9.69us 0.96x
desk_gmailthread.skp 333us -> 318us 0.96x
tabl_digg.skp 926us -> 883us 0.95x
desk_googlespreadsheet.skp 586us -> 558us 0.95x
desk_forecastio.skp 101us -> 95.7us 0.95x
desk_booking.skp 1.1ms -> 1.04ms 0.95x
tabl_deviantart.skp 144us -> 136us 0.95x
desk_facebook.skp 584us -> 553us 0.95x
desk_weather.skp 289us -> 272us 0.94x
desk_googlehome.skp 61.1us -> 57.5us 0.94x
desk_googleplus.skp 914us -> 849us 0.93x
desk_twitter.skp 499us -> 463us 0.93x
BUG=skia:
Review URL: https://codereview.chromium.org/756783002
|
mtklein
mtklein