intended uses:
- flag a SkSurface as sRGB (only supported by Ganesh for now)
- flag images (e.g. png or jpeg) as sRGB if the codec tells us that
wins:
- faster gamma-correct text (esp. w/ distance-fields) when we can use sRGB for text
- better color fidelity when the screen really is sRGB
Review URL: https://codereview.chromium.org/676883003
Add skiatest::Failure to keep track of data about a test failure.
Reporter::reportFailed and ::onReportFailed now take Failure as a
parameter. This allows the implementation to treat the failure as it
wishes. Provide a helper to format the failure the same as prior to
the change.
Update the macros for calling reportFailed (REPORTER_ASSERT etc) to
create a Failure object.
Convert a direct call to reportFailed to the macro ERRORF.
Write Failures to Json.
Sample output when running dm on the dummy test crrev.com/705723004:
{
"test_results" : {
"failures" : [
{
"condition" : "0 > 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 10,
"message" : ""
},
{
"condition" : "false",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 4,
"message" : ""
},
{
"condition" : "1 == 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 5,
"message" : "I can too count!"
},
{
"condition" : "",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 6,
"message" : "seven is 7"
},
{
"condition" : "1 == 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 14,
"message" : "I can too count!"
}
]
}
}
Report all of the failures from one test.
Previously, if one test had multiple failures, only one was reportered.
e.g:
Failures:
test Dummy: ../../tests/DummyTest.cpp:6 seven is 7
test Dummy2: ../../tests/DummyTest.cpp:10 0 > 3
test Dummy3: ../../tests/DummyTest.cpp:14 I can too count!: 1 == 3
3 failures.
Now, we get all the messages:
Failures:
test Dummy: ../../tests/DummyTest.cpp:4 false
../../tests/DummyTest.cpp:5 I can too count!: 1 == 3
../../tests/DummyTest.cpp:6 seven is 7
test Dummy2: ../../tests/DummyTest.cpp:10 0 > 3
test Dummy3: ../../tests/DummyTest.cpp:14 I can too count!: 1 == 3
3 failures.
(Note that we still state "3 failures" because 3 DM::Tasks failed.)
BUG=skia:3082
BUG=skia:2454
Review URL: https://codereview.chromium.org/694703005
This removes the code which forces 400 and 700 weights only,
and also overrides the font weight with the configured weight.
Review URL: https://codereview.chromium.org/694533006
This CL shrinks the bound computed for saveLayers that possess both an explicit
bound and a complex paint (e.g., one that affects transparent black). In this
case the bound of the layer should be the clipped explicit bound rather then
the clip prior/after the saveLayer/restore block.
In the following the first bound is the currently computed bound
while the second is the new/desired one:
For a 100x100 picture
saveLayer (no bound, no paint) [ 0 0 100 100 ] [ 50 50 100 100 ]
setMatrix (translate 50, 50) [ 0 0 100 100 ] [ 50 50 100 100 ]
saveLayer (bound of 0, 0, 50, 50 - complex paint) [ 0 0 100 100 ] [ 50 50 100 100 ]
restore [ 0 0 100 100 ] [ 50 50 100 100 ]
restore [ 0 0 100 100 ] [ 50 50 100 100 ]
Review URL: https://codereview.chromium.org/696763002
This will be a bit hairy to review.
The FillBounds and CollectLayers code has diverged significantly resulting in the rendering path seeing different bounds than the hoisting path. This CL merges the FillBounds changes into CollectLayers. A follow on CL will, hopefully, find a way to layer CollectLayers on top of FillBounds.
The only code in CollectLayers that is different from FillBounds is bracketed by "LAYER HOISTING" comments.
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/685263004
This should produce tighter conservative bounding boxes for text than the
approximation code it replaces.
Recording performance is neutral on my desktop. Playback performance
improves by up to 15% on text heavy pages, e.g.
desk_pokemonwiki.skp_1 3.24ms -> 2.83ms 0.87x
desk_baidu.skp_1 1.91ms -> 1.58ms 0.83x
Committed: https://skia.googlesource.com/skia/+/bf8dc343df4fbdcb8af546eb68b640e011a33489
CQ_EXTRA_TRYBOTS=client.skia:Test-Win7-ShuttleA-HD2000-x86-Debug-Trybot
Review URL: https://codereview.chromium.org/680363003
The SkRectShaderImageFilter had the same bug as previously fixed for
SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
the implementation, this change makes all filters with 0 inputs return
their source bounds, instead of returning false.
BUG=427251
Review URL: https://codereview.chromium.org/681643003
This should produce tighter conservative bounding boxes for text than the
approximation code it replaces.
Recording performance is neutral on my desktop. Playback performance
improves by up to 15% on text heavy pages, e.g.
desk_pokemonwiki.skp_1 3.24ms -> 2.83ms 0.87x
desk_baidu.skp_1 1.91ms -> 1.58ms 0.83x
Review URL: https://codereview.chromium.org/680363003
Reason for revert:
Compile errors on bots
Original issue's description:
> These tests stress pathops by describing the union of circle-like paths that have tiny line segments embedded and double back to create near-coincident conditions.
>
> The fixes include
> - detect when finding the active top loops between two possible answers
> - preflight chasing winding to ensure answer is consistent
> - binary search more often when quadratic intersection fails
> - add more failure paths when an intersect is missed
>
> While this fixes the chrome bug, reenabling path ops in svg should be deferred until additional fixes are landed.
>
> TBR=
> BUG=421132
>
> Committed: https://skia.googlesource.com/skia/+/6f726addf3178b01949bb389ef83cf14a1d7b6b2TBR=caryclark@google.com
NOTREECHECKS=true
NOTRY=true
BUG=421132
Review URL: https://codereview.chromium.org/686843002
The fixes include
- detect when finding the active top loops between two possible answers
- preflight chasing winding to ensure answer is consistent
- binary search more often when quadratic intersection fails
- add more failure paths when an intersect is missed
While this fixes the chrome bug, reenabling path ops in svg should be deferred until additional fixes are landed.
TBR=
BUG=421132
Review URL: https://codereview.chromium.org/633393002
This CL alters layer hoisting to defer creation of the free floating layers until they are actually needed (rather than creating _all_ the hoisted layers at the start).
It also fixes a pre vs. post Concat bug with how matrices were being accumulated.
BUG=skia:2315
Review URL: https://codereview.chromium.org/657383004
Reason for revert:
try again
Original issue's description:
> Fix bounds computation of all 0-input filters.
>
> The SkRectShaderImageFilter had the same bug as previously fixed for
> SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
> the implementation, this change makes all filters with 0 inputs return
> their source bounds, instead of returning false.
>
> BUG=427251
>
> Committed: https://skia.googlesource.com/skia/+/ba036cc82b5a543a13cafd11a19ba0e3087fca38TBR=bsalomon@google.com,senorblanco@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=427251
Review URL: https://codereview.chromium.org/678273002
The SkRectShaderImageFilter had the same bug as previously fixed for
SkBitmapSource and SkPictureImageFilter. Rather than copy-and-paste
the implementation, this change makes all filters with 0 inputs return
their source bounds, instead of returning false.
BUG=427251
Review URL: https://codereview.chromium.org/681643003
- The expected case is now a single bulk-load insert() call instead of N;
- reserve() and flushDeferredInserts() can fold into insert() now;
- SkBBH subclasses may take ownership of the bounds
This appears to be a performance no-op on both my Mac and N5. I guess
even the simplest indirect branch predictor ("same as last time") can predict
the repeated virtual calls to SkBBH::insert() perfectly.
BUG=skia:
Review URL: https://codereview.chromium.org/670213002
This is basically how blink uses the filter. Currently, I can't use it for "ShadowOnly" mode with the filter at all, but instead of copying the code and risking to have the codepaths diverge, I'm simply going to add the option here.
BUG=skia:
Review URL: https://codereview.chromium.org/646213004
Reason for revert:
Test is SkASSERTing on Macs, e.g:
http://chromegw.corp.google.com/i/client.skia/builders/Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Debug/builds/257/steps/dm/logs/stdio
210 tasks left 1737M peak 1ms test FrontBufferedStream../../src/ports/SkImageDecoder_CG.cpp:43: failed assertion "data"
Signal 11:
_sigtramp (+0x1a)
SkStreamToCGImageSource(SkStream*) (+0x62)
SkImageDecoder_CG::onDecode(SkStream*, SkBitmap*, SkImageDecoder::Mode) (+0x2e)
SkImageDecoder::decode(SkStream*, SkBitmap*, SkColorType, SkImageDecoder::Mode) (+0x81)
SkImageDecoder::DecodeStream(SkStreamRewindable*, SkBitmap*, SkColorType, SkImageDecoder::Mode, SkImageDecoder::Format*) (+0xff)
SkImageDecoder::DecodeStream(SkStreamRewindable*, SkBitmap*) (+0x31)
test_ShortFrontBufferedStream(skiatest::Reporter*) (+0x97)
skiatest::ShortFrontBufferedStreamClass::onRun(skiatest::Reporter*) (+0x19)
skiatest::Test::run() (+0x7c)
DM::CpuTestTask::draw() (+0x5a)
DM::CpuTask::run() (+0x9e)
non-virtual thunk to DM::CpuTask::run() (+0x1c)
(anonymous namespace)::ThreadPool::Loop(void*) (+0xf4)
thread_start(void*) (+0x54)
_pthread_start (+0x14b)
Original issue's description:
> Add test for new FrontBufferedStream behavior.
>
> Test for https://skia.googlesource.com/skia/+/dd5a1e094c19fa10202c37c50a1f799e5af5dac0
>
> Verify that FrontBufferedStream does not attempt to read beyond the
> end of its underlying stream.
>
> Committed: https://skia.googlesource.com/skia/+/da59f05c6738dbb9a92cad21c608cdfae53a76b2TBR=reed@google.com,scroggo@google.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/649553003
CanvasTest only checks if the state of the different canvas
implementations are consistent with the one of the default
implementation.
Because most of the draw calls are stateless and already tested in GMs
the test steps that exercices them are not useful.
BUG=skia:3054
Review URL: https://codereview.chromium.org/672273002
Add a new enum to differentiate between a complete decode and a
partial decode (with the third value being failure). Return this
value from SkImageDecoder::onDecode (in all subclasses, plus
SkImageDecoder_empty) and ::decode.
For convenience, if the enum is treated as a boolean, success and
partial success are both considered true.
Note that the static helper functions (DecodeFile etc) still return
true and false (for one thing, this allows us to continue to use
SkImageDecoder::DecodeMemory as an SkPicture::InstallPixelRefProc in
SkPicture::CreateFromStream).
Also correctly report failure in SkASTCImageDecoder::onDecode when
SkTextureCompressor::DecompressBufferFromFormat fails.
BUG=skia:3037
BUG:b/17419670
Review URL: https://codereview.chromium.org/647023006
Add a unique-per-subclass namespace tag to make Keys from different
domains comparable.
Also drop the SkPictureShader cache and convert to using the global
resource cache instead.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/668223002
The accumulated matrix state of any enclosing SkPictures must be stored separate from the picture-local CTM. Any setMatrix calls inside a layer need to replace the picture-local CTM but concatenate with the enclosing SkPicture transform state (and the transform state needed to translate the layer to the correct location in the cached GrTexture).
Review URL: https://codereview.chromium.org/639863005
Currently, the PDF backend does not support image filters (since PDF
does not have that functionality), so it simply removes them. This is
causing Chrome print preview to render incorrectly (see bug). The fix
here is to fall back to a raster device for image filters, as we used
to do in Blink. The resulting bitmap will be drawn to the destination
device as a normal main-memory-backed bitmap.
Note: this change invalidates the PDF results of all GMs containing
image filters (since they'll actually be rendered).
BUG=422144
Review URL: https://codereview.chromium.org/644323006
This is once again an issue related to logo fonts, so I don't
see any easy way to add a regression test for this.
BUG=424824
Review URL: https://codereview.chromium.org/665103002
This CL adds the clip region to the GPU layer hoisting image cache. It also switches back to the old caching behavior of using the entire CTM in the cache key rather then just the upper 2x2. This latter change is to focus more on hoisting rather then caching.
It also includes 2 smaller fixes:
a) layer's that have an image filter are no longer atlased (b.c. doing so complicates applying the image filter)
b) the result of clipping the layer's bounds to the current clip is used as the hoisted layer's size. This reduces the amount of pixels drawn to match a normal (non-hoisted) draw pass.
Review URL: https://codereview.chromium.org/640773004
Refactor SkGLContext to be actually extendable. Before, non-trivial subclass
would need to destroy the GL connection upon running the destructor. However,
the base class would run GL commands in its own destructor (with destroyed GL
connection)
Refactor so that SkGLContext subclass object creation is completely done by
the factory function. If the factory function returns a non-NULL ptr, it means the context
is usable.
The destruction is done with the destructor instead of virtual function called
upon destruction. Make the destructors not to call virtual functions, for
clarity.
Remove custom 1x1 FBO setup code from the base class. It appears not to be used
anymore.
BUG=skia:2992
Review URL: https://codereview.chromium.org/640283004
all its commands interleaved in contiguous memory. GrTRecorder also
supports extra data associated with objects, so we can store arrays
inline without having to call malloc().
Review URL: https://codereview.chromium.org/628453002
all its commands interleaved in contiguous memory. GrTBaseList also
supports extra data associated with objects, so we can store arrays
inline without having to call malloc().
Review URL: https://codereview.chromium.org/628453002
Consolidate read/write funcs in context.
Remove support for reading pixels from a surface that's not a target. It's currently broken and neither used nor tested.
Review URL: https://codereview.chromium.org/648863002
In the new MultiPictureDraw tests a single hoisted layer is reused multiple times. The previous plot locking scheme allowed GrCachedLayer objects to be aggressively deleted prematurely leaving the reusing GrHoistedLayer objects with dangling pointers.
This CL changes adds a new pseudo-ref to GrCachedLayer. (It can't be a real ref since the cached layers aren't deleted when it goes to 0).
NOTRY=true
Committed: https://skia.googlesource.com/skia/+/5c481666c9678f43e039ad605457be3854cf8de3
Review URL: https://codereview.chromium.org/640323002
I want to play around with how SkTileGrid stores its tiles. Having a
cap on the number of insert() calls can be pretty handy.
While I'm at it, I gave flush() a default empty impl. Like reserve(),
it's really an optional hook for subclasses.
BUG=skia:
Review URL: https://codereview.chromium.org/639933003
Draw thick-stroked Beziers by computing the outset quadratic, measuring the error, and subdividing until the error is within a predetermined limit.
To try this CL out, change src/core/SkStroke.h:18 to
#define QUAD_STROKE_APPROXIMATION 1
or from the command line: CPPFLAGS="-D QUAD_STROKE_APPROXIMATION=1" ./gyp_skia
Here's what's in this CL:
bench/BezierBench.cpp : a microbench for examining where the time is going
gm/beziers.cpp : random Beziers with various thicknesses
gm/smallarc.cpp : a distillation of bug skia:2769
samplecode/SampleRotateCircles.cpp : controls added for error, limit, width
src/core/SkStroke.cpp : the new stroke implementation (disabled)
tests/StrokerTest.cpp : a stroke torture test that checks normal and extreme values
The new stroke algorithm has a tweakable parameter:
stroker.setError(1); (SkStrokeRec.cpp:112)
The stroke error is the allowable gap between the midpoint of the stroke quadratic and the center Bezier. As the projection from the quadratic approaches the endpoints, the error is decreased proportionally so that it is always inside the quadratic curve.
An overview of how this works:
- For a given T range of a Bezier, compute the perpendiculars and find the points outset and inset for some radius.
- Construct tangents for the quadratic stroke.
- If the tangent don't intersect between them (may happen with cubics), subdivide.
- If the quadratic stroke end points are close (again, may happen with cubics), draw a line between them.
- Compute the quadratic formed by the intersecting tangents.
- If the midpoint of the quadratic is close to the midpoint of the Bezier perpendicular, return the quadratic.
- If the end of the stroke at the Bezier midpoint doesn't intersect the quad's bounds, subdivide.
- Find where the Bezier midpoint ray intersects the quadratic.
- If the intersection is too close to the quad's endpoints, subdivide.
- If the error is large proportional to the intersection's distance to the quad's endpoints, subdivide.
BUG=skia:723,skia:2769
Review URL: https://codereview.chromium.org/558163005
Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before,
it depended on ifdefs to implement the platform dependent polymorphism. Move
the logic to subclasses of the various platform implementations.
This a step to enable Skia embedders to compile dm and bench_pictures. The
concrete goal is to support running these test apps with Chromium command buffer.
With this change, Chromium can implement its own version of SkGLNativeContext
that uses command buffer, and host the implementation in its own repository.
Implements the above by renaming the SkGLContextHelper to SkGLContext and
removing the unneeded SkGLNativeContext. Also removes
SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused:
no use in Skia code, and no tests.
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/a90ed4e83897b45d6331ee4c54e1edd4054de9a8
Review URL: https://codereview.chromium.org/630843002
Reason for revert:
nanobech failing on Android
Original issue's description:
> Make the Sk GL context class an abstract base class
>
> Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before,
> it depended on ifdefs to implement the platform dependent polymorphism. Move
> the logic to subclasses of the various platform implementations.
>
> This a step to enable Skia embedders to compile dm and bench_pictures. The
> concrete goal is to support running these test apps with Chromium command buffer.
>
> With this change, Chromium can implement its own version of SkGLNativeContext
> that uses command buffer, and host the implementation in its own repository.
>
> Implements the above by renaming the SkGLContextHelper to SkGLContext and
> removing the unneeded SkGLNativeContext. Also removes
> SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused:
> no use in Skia code, and no tests.
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/a90ed4e83897b45d6331ee4c54e1edd4054de9a8TBR=kkinnunen@nvidia.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/639793002
Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before,
it depended on ifdefs to implement the platform dependent polymorphism. Move
the logic to subclasses of the various platform implementations.
This a step to enable Skia embedders to compile dm and bench_pictures. The
concrete goal is to support running these test apps with Chromium command buffer.
With this change, Chromium can implement its own version of SkGLNativeContext
that uses command buffer, and host the implementation in its own repository.
Implements the above by renaming the SkGLContextHelper to SkGLContext and
removing the unneeded SkGLNativeContext. Also removes
SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused:
no use in Skia code, and no tests.
BUG=skia:2992
Review URL: https://codereview.chromium.org/630843002
this is a huge refactor and cleanup of the gl shader building system in
Skia. The entire shader building pipeline is now part of
GrGLProgramCreator, which takes a gp, and some fps, and creates a
program. I added some subclasses of GrGLProgram to handle the
eccentricities of Nvpr/Nvpres. Outside of the builders folder
and GrGLPrograms, this change is basically just a rename
solo gp
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/fe1233c3f12f81bb675718516bbb32f72af726ec
Review URL: https://codereview.chromium.org/611653002
Reason for revert:
Seems to have messed up windows 7 gms
Original issue's description:
> Cleanup of shader building system
>
> this is a huge refactor and cleanup of the gl shader building system in
> Skia. The entire shader building pipeline is now part of
> GrGLProgramCreator, which takes a gp, and some fps, and creates a
> program. I added some subclasses of GrGLProgram to handle the
> eccentricities of Nvpr/Nvpres. Outside of the builders folder
> and GrGLPrograms, this change is basically just a rename
>
>
> solo gp
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/fe1233c3f12f81bb675718516bbb32f72af726ecTBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/635533005
this is a huge refactor and cleanup of the gl shader building system in
Skia. The entire shader building pipeline is now part of
GrGLProgramCreator, which takes a gp, and some fps, and creates a
program. I added some subclasses of GrGLProgram to handle the
eccentricities of Nvpr/Nvpres. Outside of the builders folder
and GrGLPrograms, this change is basically just a rename
solo gp
BUG=skia:
Review URL: https://codereview.chromium.org/611653002
Reason for revert:
Changing some GMs
Original issue's description:
> Add isSingleComponent bool to getConstantColorComponent
>
> Initial step to allowing effects to use/output 1 or 4 color/coverage components. This cl doesn't change any current logic and all effects still assume they are working with 4 components.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3b8af078281a5a20f951b9fd84f38d92b8f6217bTBR=joshualitt@chromium.org,bsalomon@google.com,reed@google.com,egdaniel@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/617853003
Initial step to allowing effects to use/output 1 or 4 color/coverage components. This cl doesn't change any current logic and all effects still assume they are working with 4 components.
BUG=skia:
Review URL: https://codereview.chromium.org/608253002
Now that the old backend's not using BBHs, we can specialize them for
SkRecord's needs. The only thing we really want to store is op index, which
should always be small enough to fit into an unsigned (unsigned also helps keep
it straight from other ints floating around).
This means we'll need half (32-bit) or a quarter (64-bit) the bytes in SkTileGrid,
because we don't have to store an extra int for ordering.
BUG=skia:2834
Review URL: https://codereview.chromium.org/617393004
It makes no sense for the paint from a saveLayer to effect anything outside its saveLayer/restore block. But as currently written, we'll adjust the clip bounds just after a restore by that paint.
Turns out the test I wrote for the last CL (which caused this bug) actually had the bug baked into its expectations. I've updated them and added some notes to explain.
BUG=418417
Review URL: https://codereview.chromium.org/623563002
This removes:
1) ability to record old pictures with SkPictureRecorder;
2) a couple tests specific to the old backend.
The functionality of DEPRECATED_beginRecording() now lives in
(private) SkPicture::Backport(), which is the only place we
need it now.
BUG=skia:
TBR=reed@google.com
Review URL: https://codereview.chromium.org/618303002
Having hoisted layers from different pictures invalidates the assumptions of the old GrReplacements object. This is fixed by switching to a SkTDynamicHash-based back-end.
Sub-picture-layers also require that the replacement drawing occur for the sub-pictures too. The ReplaceDraw object is added to make this happen and limit the replacement lookup to saveLayer draw commands.
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
Review URL: https://codereview.chromium.org/607763008
Feature-wise, this removes:
1) BBH support;
2) peephole optimizations;
3) record-time text op specializations;
4) the guarantee that SkPaints are flattened.
This deletes the optimizations GM, which only exists to test the peepholes of
the old backend. SkRecord optimizations are unit tested, and if that ever fails we
can think about adding another GM like this, but they're different enough we'd
want to start from scratch anyway.
We need to keep the code that plays back the specialized text ops around for
a while for compatibility with existing .SKPs that have those ops recorded.
BUG=skia:
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/617953002
This CL reduces the amount of information used in the layer cache key:
- the stop value isn't needed since the start value uniquely identifies the layer in the picture.
- only the upper-left 2x2 portion of the CTM should be used as a key for looking up cached layers.
- individual layers can be redraw in different locations so the final offset cannot be a part of the key.
Since this data is no longer stored in the cached layer, but is still required to draw the cached layer, it is now stored in the per-layer information (i.e., HoistedLayer).
This is split out of (Fix sub-picture layer rendering bugs - https://codereview.chromium.org/597293002/).
BUG=skia:2315
R=egdaniel@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/609403003
fDirtyBits is only used by SkPaint::FlatteningTraits, which in turn was
only used as a smaller, faster format to flatten paints in-memory to dedup
them in the old picture backend.
SkRecord obsoleted all this. Neither flatten()/unflatten() (disk format)
nor FlatteningTraits is used anywhere performance or size matters.
Here I revert the deduping code back to using the disk format for flattened paints.
We stil do have to flatten and unflatten paints while coverting from SkRecord
backend to the old backend, so we can't just delete this all yet, but any
faithful round trip flatten()/unflatten() pair will be fine, however slow.
NOTRY=true
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/604813003
Before this CL, SkRecord only adjusted the bounds of draw ops for SaveLayers' paints.
That worked fine, but as a final step we intersect the bounds of draw ops with the
bounds of the current clip, essentially undoing all that work.
I think the right fix here is to also adjust the bounds of the clip ops.
BUG=skia:2957, 415468
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/595953002
Refactored text blob backend for improved performance: instead of using
separate buffers for runs/positions/glyphs, everything is now packed in
a consolidated slab (including the SkTextBlob object itself!).
Benefits:
* number of allocations per blob construction reduced from ~4 to 1
(also minimizes internal fragmentation)
* run record size reduced by 8 bytes
This takes the blob construction overhead down to negligible levels
(for the current Blink uncached textblob implementation).
Unfortunately, the code is much more finicky (run merging in
particular) -- hence the assert spree.
Multi-run blobs are vulnerable to realloc storms but this is not a
problem at the moment because Blink is using one-run blobs 99% of the
time. Will be addressed in the future.
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Committed: https://skia.googlesource.com/skia/+/13645ea0ea87038ebd71be3bd6d53b313069a9e4
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/581173003
Reason for revert:
Broke the new blobshader gm.
Original issue's description:
> Souped-up SkTextBlob.
>
> Refactored text blob backend for improved performance: instead of using
> separate buffers for runs/positions/glyphs, everything is now packed in
> a consolidated slab (including the SkTextBlob object itself!).
>
> Benefits:
>
> * number of allocations per blob construction reduced from ~4 to 1
> (also minimizes internal fragmentation)
> * run record size reduced by 8 bytes
>
> This takes the blob construction overhead down to negligible levels
> (for the current Blink uncached textblob implementation).
>
> Unfortunately, the code is much more finicky (run merging in
> particular) -- hence the assert spree.
>
> Multi-run blobs are vulnerable to realloc storms but this is not a
> problem at the moment because Blink is using one-run blobs 99% of the
> time. Will be addressed in the future.
>
>
> R=reed@google.com,mtklein@google.com,robertphillips@google.com
>
> Committed: https://skia.googlesource.com/skia/+/13645ea0ea87038ebd71be3bd6d53b313069a9e4R=mtklein@google.com, reed@google.com, robertphillips@google.comTBR=mtklein@google.com, reed@google.com, robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/588853002
Refactored text blob backend for improved performance: instead of using
separate buffers for runs/positions/glyphs, everything is now packed in
a consolidated slab (including the SkTextBlob object itself!).
Benefits:
* number of allocations per blob construction reduced from ~4 to 1
(also minimizes internal fragmentation)
* run record size reduced by 8 bytes
This takes the blob construction overhead down to negligible levels
(for the current Blink uncached textblob implementation).
Unfortunately, the code is much more finicky (run merging in
particular) -- hence the assert spree.
Multi-run blobs are vulnerable to realloc storms but this is not a
problem at the moment because Blink is using one-run blobs 99% of the
time. Will be addressed in the future.
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/581173003
This is intended to disconnect the lifetimes of the optimization data, cached layers and replacement objects.
Note that the optimization data already makes a copy of the paint in the SkPicture. Additionally the replacement object will probably go away at some point.
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/579843002
This is a bit like a limited SkData, geared to store really tiny byte strings.
This is not hooked up anywhere beyond the new unit test. I did experimentally
plumb it into SkRecord for drawPosTextH: just over 40% of drawPosTextH calls in
our repo can fit into ShortData.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/573323002
blink skips all pending commands during picture recording if it is drawing an opaque full-frame
geometry or image. This may improve performance for some edge cases. To recognize an opaque
full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement.
Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame
is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process.
benchmark percentage
my local benchmark(draw 1000 sprites) 4.1%
speedReading 2.8%
FishIETank(1000 fishes) 1.5%
GUIMark3 Bitmap 2.0%
By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization
(GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently,
SkDeferredCanvas::isFullFrame() is nontrivial.
getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and
reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times)
of isFullFrame().
telemetry smoothness canvas_tough_test didn't show obvious improvement or regression.
BUG=411166
Committed: https://skia.googlesource.com/skia/+/8e45c3777d886ba3fe239bb549d06b0693692152R=junov@chromium.org, tomhudson@google.com, reed@google.com
Author: yunchao.he@intel.com
Review URL: https://codereview.chromium.org/545813002
Reason for revert:
This is leaking memory:
http://108.170.220.120:10117/builders/Test-Ubuntu13.10-GCE-NoGPU-x86_64-Debug-ASAN/builds/2516/steps/RunDM/logs/stdio
Original issue's description:
> Picture Recording: fix the performance bottleneck in SkDeferredCanvas::isFullFrame
>
> blink skips all pending commands during picture recording if it is drawing an opaque full-frame
> geometry or image. This may improve performance for some edge cases. To recognize an opaque
> full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement.
> Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame
> is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process.
>
> benchmark percentage
> my local benchmark(draw 1000 sprites) 4.1%
> speedReading 2.8%
> FishIETank(1000 fishes) 1.5%
> GUIMark3 Bitmap 2.0%
>
> By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization
> (GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently,
> SkDeferredCanvas::isFullFrame() is nontrivial.
>
> getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and
> reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times)
> of isFullFrame().
>
> telemetry smoothness canvas_tough_test didn't show obvious improvement or regression.
>
> BUG=411166
>
> Committed: https://skia.googlesource.com/skia/+/8e45c3777d886ba3fe239bb549d06b0693692152R=junov@chromium.org, tomhudson@google.com, reed@google.com, yunchao.he@intel.comTBR=junov@chromium.org, reed@google.com, tomhudson@google.com, yunchao.he@intel.com
NOTREECHECKS=true
NOTRY=true
BUG=411166
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/571053002
blink skips all pending commands during picture recording if it is drawing an opaque full-frame
geometry or image. This may improve performance for some edge cases. To recognize an opaque
full-frame drawing should be cheap enough. Otherwise, the overhead will offset the improvement.
Unfortunately, data from perf for content_shell on Nexus7 shows that SkDeferredCanvas::isFullFrame
is far from cheap. Table below shows that how much isFullFrame() costs in the whole render process.
benchmark percentage
my local benchmark(draw 1000 sprites) 4.1%
speedReading 2.8%
FishIETank(1000 fishes) 1.5%
GUIMark3 Bitmap 2.0%
By contrast, real recording (SkGPipeCanvas::drawBitmapRectToRect) and real rasterization
(GrDrawTarget::drawRect) cost ~4% and ~6% in the whole render process respectively. Apparently,
SkDeferredCanvas::isFullFrame() is nontrivial.
getDeviceSize() is the main contributor to this hotspot. The change simply save the canvasSize and
reuse it among drawings if it is not a fresh frame. This change cut off ~65% (or improved ~2 times)
of isFullFrame().
telemetry smoothness canvas_tough_test didn't show obvious improvement or regression.
BUG=411166
R=junov@chromium.org, tomhudson@google.com, reed@google.com
Author: yunchao.he@intel.com
Review URL: https://codereview.chromium.org/545813002
This adds SkResourceCache::Remove() which will remove a resource from
its cache. The resource is required to be unlocked at the time Remove()
is called.
Then SkBitmapCache::Find() makes use of this to Remove() bitmaps from
the cache whose pixels have been evicted. This allows the bitmap to be
re-added to the cache with pixels again.
After this change, background a tab (and discarding all the bitmaps'
contents) no longer disables image caching for those discarded images
once the tab is visible again.
BUG=skia:2926
NOTRY=true
R=reed@android.com, tomhudson@google.com, reed@google.com
Author: danakj@chromium.org
Review URL: https://codereview.chromium.org/561953002
There are two ways negative sigma values may occur: in
the original filter parameters, or after multiplication
by a negative scaling CTM. The former case is
invalid according to the spec, so we continue to check
for it at validation time. In the latter case, we should
interpret it as a horizontal flip in the kernel pixel
access, and simply take the absolute value (since the
filter kernel is symmetric).
Also refactor all this logic into a single place for the
CPU, GPU and onFilterBounds() paths.
BUG=https://code.google.com/p/chromium/issues/detail?id=409602R=sugoi@google.com, reed@google.com, sugoi@chromium.org
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/555603002
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
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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=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
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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.orgTBR=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
Scale all images to the nearest rounded integer, and if there's still
any scaling factor left over, pass it on to the subsequent bilerp code.
Should avoid artifacts when tiling scaled images.
Original CL received an LGTM from reed; new version disabled tiling
in the downsamplebitmap GM; I verified that this fixes the issue
we were seeing there on non-neon androids.
BUG=skia:2888
R=reed@android.com
TBR=reed
Author: humper@google.com
Review URL: https://codereview.chromium.org/514383003
When calling cubicTo(a, b, c) and if the distance between fPrevPt and a
is too small, b is used instead of a to calculate the first tangent,
even if the distance between fPrevPt and b is too small.
In debug mode, this is causing an assertion to fail in
SkPathStroker::preJoinTo() and, in Release, the use of an
unitialized value.
The first patch set is adding a failing test.
The second one add the fix to SkPathStroker::cubicTo()
BUG=skia:2820
R=bsalomon@chromium.org, junov@chromium.org, reed@google.com, caryclark@google.com, bsalomon@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/460813002
Implement support for NV_path_rendering on OpenGL ES. Use
glProgramPathFragmentInputGenNV function call instead of glPathTexGenNV to
communicate transforms to fragment shader.
The intention is that the NVPR paths will be drawn with the same shader program
as non-NVPR geometry. For NVPR calls, the GPU will skip the vertex shader and
just run the fragment shader.
After program is linked, query the locations of the fragment shader inputs with
glGetResourceLocation. The location will be used to set the transforms with
glProgramPathFragmentInputGenNV.
The functions and their workings are documented in:
glProgramPathFragmentInputGenNV
https://www.opengl.org/registry/specs/NV/path_rendering.txt
(note: addition as of API version 1.3)
glGetResourceLocation
https://www.opengl.org/registry/specs/ARB/program_interface_query.txthttp://www.opengl.org/registry/doc/glspec44.core.pdf
(function is in core Open GL 4.4)
Note: glProgramPathFragmentInputGenNV could be used also for OpenGL. However,
using seems to trigger a bug in the driver. Disable this feature on OpenGL at
least until the driver is fixed and released. The bug manifests in shadertext
test, where the lower-left text pair is missing. Valgrind catches a bad read
for the test and causes the context to OOM reproducibly.
R=bsalomon@google.com, cdalton@nvidia.com, joshualitt@google.com, joshualitt@chromium.org
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/367643004
