Remove SkLCGRandom. We already decided the new one was better, which is
why we wrote the new SkRandom.
Convert GMs that were using SkLCGRandom to use the improved SkRandom.
Motivated by the fact that these GMs draw differently on some runs. We
believe this to be a result of using the old SkLCGRandom.
Add each of the tests that were using SkLCGRandom to ignore-tests.txt,
since we expect they'll draw differently using SkRandom.
Move a trimmed down version of SkLCGRandom into SkDiscretePathEffect.
In order to preserve the old behavior, trim down SkLCGRandom to only
the methods used by SkDiscretePathEffect, and hide it in
SkDiscretePathEffect's cpp file.
BUG=skia:3241
Review URL: https://codereview.chromium.org/805963002
This is needed since clearColorStages is being changed to ignore color input. For RGB coverage,
we want to clear all the color stages (since we know the final output color), but we don't want
to ignore the color input since it is needed.
In future we will change this so the XP stores the color internally and thus can tell the GP to
simiply ignore color.
BUG=skia:
Review URL: https://codereview.chromium.org/791933006
This was done automatically by running clang-modernize -add-override -override-macros.
It's not clear to me whether include/ is already clean or I just can't get the tool to work for headers.
BUG=skia:
Review URL: https://codereview.chromium.org/808463002
This fixes errors like this:
../../include/gpu/effects/GrPorterDuffXferProcessor.h:27:25: error:
'name' overrides a member function but is not marked 'override'
[-Werror,-Winconsistent-missing-override]
BUG=skia:3075
TEST=ninja -C out/Debug skia_lib
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/804813002
When we added the 64K allocation cap, the bots showed we took a perf hit
on some large .skps like desk_pokemonwiki.skp, despite not seeing a local
effect. I'm still not seeing that locally, but I'd like to try removing the cap on
the bots to see what happens. For big monolithic pictures, really packing into
memory tightly is probably not as important as it is for tiny ones.
Similarly, we're probably being too cautious about making tiny allocations.
Today we start at 16 bytes, which isn't really enough to record anything.
Even the smallest picture, say,
save
clipRect
drawRect
restore
requires ~200 bytes, so we might as well move our minimum block size up
near there.
I don't know if 16 bytes is too small to start for GrTextStrikes, so I've left the
behavior the same (though the max is still gone).
Local recording performance is neutral-to-positive:
tabl_deviantart.skp 126us -> 129us 1.02x
tabl_nytimes.skp 110us -> 112us 1.02x
tabl_cuteoverload.skp 521us -> 530us 1.02x
desk_mobilenews.skp 673us -> 682us 1.01x
desk_chalkboard.skp 843us -> 854us 1.01x
desk_sfgate.skp 528us -> 535us 1.01x
desk_silkfinance.skp 68.2us -> 69us 1.01x
desk_youtube.skp 623us -> 629us 1.01x
desk_blogger.skp 472us -> 475us 1.01x
desk_jsfiddlehumperclip.skp 42.2us -> 42.5us 1.01x
desk_espn.skp 255us -> 256us 1.01x
desk_ebay.skp 174us -> 174us 1x
desk_twitter.skp 454us -> 455us 1x
tabl_pravda.skp 200us -> 201us 1x
desk_wordpress.skp 782us -> 784us 1x
desk_samoasvg.skp 762us -> 761us 1x
tabl_mozilla.skp 1.58ms -> 1.58ms 1x
tabl_slashdot.skp 107us -> 107us 1x
tabl_techmeme.skp 102us -> 102us 0.99x
tabl_gamedeksiam.skp 729us -> 724us 0.99x
tabl_nofolo.skp 65.3us -> 64.7us 0.99x
desk_gmailthread.skp 339us -> 336us 0.99x
tabl_sahadan.skp 91us -> 90us 0.99x
desk_yahooanswers.skp 144us -> 142us 0.99x
tabl_cnet.skp 143us -> 141us 0.99x
tabl_googleblog.skp 206us -> 203us 0.99x
tabl_cnn.skp 160us -> 158us 0.99x
tabl_frantzen.skp 50.5us -> 49.6us 0.98x
desk_linkedin.skp 328us -> 323us 0.98x
tabl_digg.skp 790us -> 769us 0.97x
desk_jsfiddlebigcar.skp 40.6us -> 39.5us 0.97x
desk_mapsvg.skp 1.57ms -> 1.52ms 0.97x
tabl_gmail.skp 19.4us -> 18.6us 0.96x
tabl_hsfi.skp 9.81us -> 9.11us 0.93x
BUG=skia:
Review URL: https://codereview.chromium.org/793033002
It's unclear what params should be used for half float alpha
rendertargets, so they are disabled for the moment.
Review URL: https://codereview.chromium.org/799593002
No runtime difference here, but it makes it impossible to forget to make
a shallow copy; you can't get at the full bitmap without it.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/799603002
We can't do this unconditionally or pipe will become stupidly slow.
DM's serialize mode fails subtly on Mac when we force embedding, so I've
#ifdef'd that away. Other platforms look fine.
BUG=skia:
Review URL: https://codereview.chromium.org/796523002
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
Exposing SkSurface_Gpu makes me sad and I would welcome alternatives.
This change is desireable since it greatly decreases the render target swaps.
Review URL: https://codereview.chromium.org/792923002
OSX10.9 and iOS7.0 deprecated CGContextShowGlyphsAtPoint so a new API
should be used. OSX10.7 and iOS4.2 replace CGContextShowGlyphsAtPoint with
CTFontDrawGlyphs. OSX10.5 and iOS2.0 have CGContextShowGlyphsAtPositions
which works similarly to CTFontDrawGlyphs and has not yet been deprecated.
This change allows the use of CTFontDrawGlyphs when it is available,
falling back to CGContextShowGlyphsAtPositions when it isn't.
Review URL: https://codereview.chromium.org/770383002
This prevents races when calling fPtsToUnit.getType() from multiple threads.
This introduces a small amount of redundant code in SkTwoPointRadialGradient,
but it's probably optimized together into no extra run-time work.
BUG=437511
Review URL: https://codereview.chromium.org/793763003
Previously, a function was called using dlsym in skia_launcher.
Add a static initializer that changes the setting, and include that for
the tools we automate for testing.
Also only do va_copy if we actually use it.
BUG=skia:2454
Review URL: https://codereview.chromium.org/753543003
This includes:
-Having an actual XP stage at the end of the gl pipeline.
-All Blending work is handled by XP until actually setting GL blend states
-GLPrograms test to test XP
BUG=skia:
Review URL: https://codereview.chromium.org/764643004
With this CL, related nanobench can be improved for 565 config.
bitmap_BGRA_8888_update_scale_bilerp 76.1us -> 46.7us 0.61x
bitmap_BGRA_8888_scale_bilerp 78.7us -> 47us 0.6x
bitmap_BGRA_8888_update_volatile_scale_bilerp 82.7us -> 46.9us 0.57x
BUG=skia:
Review URL: https://codereview.chromium.org/788853002
GrGlTextureRenderTarget inherits virtually from both GrGlRenderTarget and
GrGLTexture, which both have a 'wrap' flag. The passed in wrap setting could
be different for the two base classes, but since it's virtually inherited,
they share the same flag, so they're either both on, or both off.
As a result, we fail to delete the frambuffer.
To fix this, we now keep a separate isWrapped flag for GrGlRenderTarget.
BUG=437998
Review URL: https://codereview.chromium.org/791493003
In addition, NVPR makes this very complicated, and I haven't quite figured out a good way to handle it, so for now color and coverage DO live on optstate, but I will figure out some way to refactor that in future CLs.
BUG=skia:
Review URL: https://codereview.chromium.org/783763002
Nexus 6 appears to require a sized internal format for A8 textures, much
like other newer mobile devices. Changed to use sized format for A8
textures in general with ES 3.0.
Review URL: https://codereview.chromium.org/783523003
Reason for revert:
Compilation is failing on some bots
Original issue's description:
> Replace EncodeBitmap with an interface.
>
> Gives more flexibility to the caller to decide whether to use the
> encoded data returned by refEncodedData().
>
> Provides an implementation that supports the old version of
> SkPicture::serialize().
>
> TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
>
> BUG=skia:3190
>
> Committed: https://skia.googlesource.com/skia/+/0c4aba6edb9900c597359dfa49d3ce4a41bc5dd1TBR=reed@google.com,scroggo@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:3190
Review URL: https://codereview.chromium.org/787833002
This CL makes the bounding box returned from SkMatrixImageFilter::computeFastBounds actually contain the final result pixels. This, in turn, fixes the first two rows of the filterfastbounds GM and the SVG web page cited in the bug.
BUG=418417
Review URL: https://codereview.chromium.org/785893004
Gives more flexibility to the caller to decide whether to use the
encoded data returned by refEncodedData().
Provides an implementation that supports the old version of
SkPicture::serialize().
TODO: Update Chrome, so we can remove SK_LEGACY_ENCODE_BITMAP entirely
BUG=skia:3190
Review URL: https://codereview.chromium.org/784643002
Reason for revert:
break many gm's
Original issue's description:
> Make all blending up to GrOptDrawState be handled by the xp/xp factory.
>
> In this cl the blending information is extracted for the xp and stored in the ODS
> which is then used as it currently is. In the follow up cl, an XP backend will be added
> and at that point all blending work will take place inside XP's.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7c66342a399b529634bed0fabfaa562db2c0dbd4TBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/766653008
In this cl the blending information is extracted for the xp and stored in the ODS
which is then used as it currently is. In the follow up cl, an XP backend will be added
and at that point all blending work will take place inside XP's.
BUG=skia:
Review URL: https://codereview.chromium.org/759713002
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
PathOps relies on isConvex() only returning true for trivially
convex paths. The old logic also returns true if the paths that
contain NaNs and Infinities. Return kUnknown_Convexity instead
in those cases and in cases where the convexity logic computes
intermediaries that overflow.
Review URL: https://codereview.chromium.org/784593002
This allows us to create distance field textures with better precision,
which may help text quality.
BUG=skia:3103
Review URL: https://codereview.chromium.org/762923003
All of our font back-ends use the text size in some way other than
simple concatentation with the current matrix. The code here finds
the full device matrix and then decomposes it to extract the text
size.
FreeType, GDI, and DirectWrite use the text size as the pre-hint scale.
CoreText will not scale color emoji above the requested text size,
and certain features like 'trak' are performed on the text size.
Review URL: https://codereview.chromium.org/748883005
Rename GrTextStrike.{cpp.h} to GrFontCache.{cpp,h}
Move contents of GrTextStrike_impl.h to GrFontCache.h
Move glyph uploading to a separate function and remove harmful gotos
Add assert on glyph upload failure (shouldn't happen)
Review URL: https://codereview.chromium.org/780923002
Two issues with the SKPBench tile computation were causing the MPD path to do more work:
The clip from the parent canvas wasn't being used to trim content off the edges of the MPD tiles
The non-MPD path was not taking the scale into account in its tile placement (resulting in it having fewer, larger active tiles when scaling).
Review URL: https://codereview.chromium.org/776273002
