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
It is desirable that, when layer hoisting is disabled, the MPD and non-MPD timings be
roughly the same. Unfortunately, using a separate canvas for each tile (a requirement
for MPD) introduces its own discrepancy into the timing. Using a separate canvas for
each tile doesn't seem to make a difference for 8888 (see the non-MPD 8888 column below)
but slows down GPU rendering (see the non-MPD GPU column below). Since this is how
Chromium renders I propose switching to this regimen (even though it is "slowing down"
GPU rendering).
nanobench mean times (ms) with layer hoisting disabled (for desk_amazon.skp)
8888
MPD non-MPD
1 canvas (old-style) 0.628 1.71
separate (new-style) 0.795 1.63
GPU
MPD non-MPD
1 canvas (old-style) 2.34 1.69
separate (new-style) 2.32 2.66
Review URL: https://codereview.chromium.org/779643002
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
This new GM visualizes the fast bounds computed by various image-filter-based SkPaints. This is lead up to fixing some issues in fast bound computation.
BUG=418417
Review URL: https://codereview.chromium.org/788613003
