In our current setup, there is no need for storing the sampled images in an
array and then putting in barriers for them later. If we ever change the
system to building up these secondary command buffers early, we will need
to go back to storing the sampled images.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302333002
Review-Url: https://codereview.chromium.org/2302333002
I think is a good redesign that will allow us to handle more png
xforms more efficiently. And I also think it reduces a bit of
complexity.
PNGs can be RGBA, RGB, Gray, GrayAlpha, Index8.
The swizzler handles all of those input formats and all Skia
output formats. Swizzler also provides sampling/subsetting.
Color xforms currently only handles RGBA. So we use the
swizzler to convert to RGBA first. I've started thinking
about adding RGB, Gray, etc. support for color xforms.
In this case (and the RGBA case), we should skip the
swizzling step.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2279313003
Review-Url: https://codereview.chromium.org/2279313003
I am hoping this makes it easier to get *SAN bots going.
Today we're generating a libcompiler_rt.a that's using a
relocation type that the ld on the bots doesn't know about.
This lld is will know about anything our Clang generates.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2301273002
Review-Url: https://codereview.chromium.org/2301273002
The remaining suppression (libwebp) is already covered by the
compile-time blacklist, tools/xsan.blacklist.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300193002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot,Test-Ubuntu-Clang-Golo-GPU-GT610-x86_64-Release-TSAN-Trybot
Review-Url: https://codereview.chromium.org/2300193002
This file will be imported by Chrome to access the sources lists.
Once Chrome is updated to use this file, changes to the skia .gypi layout can
be done entirely within the skia repository as long as the resulting lists
produced by the new .gni file have the same name.
Marks skia_for_chromium_defines as obsolete and moves the definition into the new .gni file. We can remove the .gypi file when Chrome is updated.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302803005
Review-Url: https://codereview.chromium.org/2302803005
'static const' means, there must be at most one of these, and initialize it at
compile time if possible or runtime if necessary. This leads to unexpected
code execution, and TSAN* will complain about races on the guard variables.
Generally 'constexpr' or 'const' are better choices. Neither can cause races:
they're either intialized at compile time (constexpr) or intialized each time
independently (const).
This CL prefers constexpr where possible, and uses const where not. It even
prefers constexpr over const where they don't make a difference... I want to have
lots of examples of constexpr for people to see and mimic.
The scoped-to-class static has nothing to do with any of this, and is not changed.
* Not yet on the bots, which use an older TSAN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300623005
Review-Url: https://codereview.chromium.org/2300623005
This will enable the new path renderer in Skia. It is still disabled
in Chrome, to protect layout test results.
Note: this will cause minor pixel diffs in a number of GMs' GPU results,
including drawregionmodes, dstreadshuffle, smallarc, path-reverse,
bug339297, parsedpaths, zero_control_stroke, strokedlines, smallpaths,
circular_arcs_stroke_round, concavepaths, circular_arcs_stroke_square,
clipcubic, arcto, persp_shaders_aa, complexclip3_complex,
circular_arcs_stroke_and_fill_butt, complexclip_aa,
complexclip_aa_layer, complexclip_aa_invert, complexclip3_simple,
complexclip_aa_layer_invert, shadertext, shadertext2,
convex-lineonly-paths-stroke-and-fill, poly2poly, glyph_pos_h_b,
glyph_pos_h_f, glyph_pos_n_f, and glyph_pos_n_s.
Note: it also "fixes" crbug_640176, or more accurately, hides the
failure, since the default path renderer likely still has the bug.
BUG=642376
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2303743002
Review-Url: https://codereview.chromium.org/2303743002
* fixed a couple of spots where using { } instead of an explicit constructor call resulted in errors
* Type::Field had a deleted copy constructor and therefore was not working inside std::vector; had to remove const from fields and change fType from a reference to a pointer
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300023002
Review-Url: https://codereview.chromium.org/2300023002
This way you don't need to set LSAN_SUPPRESSIONS in your environment...
sort of foolproof this way.
I _think_ the strdup() business from skia:2916 is actually rooted in
libfontconfig, so one suppression should cover both old ones.
I'll leave the file empty until I clean up mention of it in bot recipes.
BUG=skia:2916
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2295153003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot
Review-Url: https://codereview.chromium.org/2295153003
This is working towards fixing all bugs around simplifying the tiger.
This installment simplifies the point-t intersection list as it is built rather than doing the analysis once the intersections are complete. This avoids getting the list in an inconsistent state and makes coincident checks faster and more stable.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2237223002TBR=reed@google.com
BUG=skia:5131
Review-Url: https://codereview.chromium.org/2237223002
This seems to fix text extraction on Adobe Reader
- Registry/Ordering is now set to Skia/SkiaOrdering.
- Type3 fonts now get a FontDescriptor (force symbolic font).
- CMapName is now Skia-Identity-SkiaOrdering
- CMap behaves correctly for single-byte fonts.
Also:
- SkTestTypeface returns tounicode map for testing.
- Unit test updated
All PDFs render the same
BUG=skia:5606
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292303004
Review-Url: https://codereview.chromium.org/2292303004
This is an approach to antialiased concave path rendering
on the GPU without using MSAA. It uses GrTessellator to
extract boundary contours from the given path, then
inflates by half a pixel in screen space each direction,
then renders the result with zero alpha on the outer
contour and one alpha on in the inner contour. This
requires two passes through the tessellation code: one
to extract the boundaries, then one to tessellate the
result.
This gives approximately a 3X improvement on the IE
chalkboard demo in non-MSAA mode, a 30-40% improvement
on MotionMark's "Fill Paths", and a ~3X improvement on
MotionMark's "canvas arcTo segments".
It works best for large, simple paths, so there's currently
a limit of 10 verbs in the onCanDrawPath() check. This
dovetails nicely with the distance field path renderer's
support for small, detailed (and cached) paths.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
NOTRY=true
Review-Url: https://codereview.chromium.org/1152733009
When we have a general layout, we need to always add a barrier even if
leaving the layout in general since we don't know what the use case for
general was with the old layout.
This doesn't seem to fix any of our synchronization issues which makes
sense since we don't really use a general layout much. The only place it
is used is for mipmap generation, but then we add explicit barriers in
that function itself and the first use of the image after mipmap generation
will change the layout to something other than general, usually SHADER_READ.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2298483002
Review-Url: https://codereview.chromium.org/2298483002
