For some users of SkPictureRecorder, the cull rect is more efficiently
determined while drawing is in progress, rather than when recording starts.
The existing API requires the cull rect at start time, even though the
information is not used for any culling purpose until the end of recording.
This patch provides a means to reset the cull rect when recording ends,
allowing users to update the rect based on information learned during
drawing and for the new rect to be used as the culling bound. A valid
bound is still required on the beginRecording call because
it sizes the underlying canvas and sets the aspect ratio for any bounding
box hierarchy. The bounding box factory can also be specified and parameters
that control SkPicture creation.
R=mtklein, reed1
BUG=skia:3919
Review URL: https://codereview.chromium.org/1178673007
to compute the overlapping ranges and combine the winding
into a single destination.
This computes coincidence more rigorously, fixing the
edge cases exposed by this bug.
Also, add the ability to debug and dump pathop structures
from the coincident context.
TBR=reed@google.com
BUG=skia:3651
Review URL: https://codereview.chromium.org/1182493015
the bottom of the image. In our code before this patch,
this would result in cleanup code in onFinish() never being
called.
We can allow subclasses to take ownership of the
SkScanlineDecoder in order to make sure that it is
finished/deleted before deleting the decode manager.
BUG=skia:
Review URL: https://codereview.chromium.org/1212593003
This patch ensures that when inverting a SkMatrix44, we handle small
floats properly. When inverted these can cause infinite values, but
still evaluate to true in an if condition.
BUG=chromium:498516
Review URL: https://codereview.chromium.org/1209763002
A path can be non-empty but become empty when it is simplified.
For instance, a path with the same rectangle, twice, with opposite
windings.
No contours are created for empty paths, so don't try to
fix their winding direction.
Additionally, check for a NULL coincidence since the
OpBuilder assumes that no concidence edges can be present
after the paths are simplified. This code should not get
called, but it's worth the future-proofing to check.
R=fmalita@chromium.org
BUG=502792
Review URL: https://codereview.chromium.org/1218863005
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
There are a number of files with 'FontConfig' in their names which
just have to do with font configuration, but nothing to do with
the FontConfig project or even with each other. This clarifies
that these files deal with parsing for the Android font manager.
Review URL: https://codereview.chromium.org/1200103008
Start moving to a world where everyone provides surface properties.
Most notably this exposes a portion of SkSurfaceProps to the C API.
BUG=skia:3934
Review URL: https://codereview.chromium.org/1195003003
This CL continues cleaning up Skia's usage of SkSurfaceProps. It:
Removes the duplicate SkSurfaceProps object from SkImageFilter::Proxy.
Removes a dispreferred ctor from SkCanvas
Removes the initForRootLayer entry point from SkDevice (since the root device and the canvas should always have the same pixel geometry now).
Review URL: https://codereview.chromium.org/1201983006
Mostly this is about ergonomics, making it easier to do good operations and hard / impossible to do bad ones.
- SkAlpha / SkPMColor constructors become static factories.
- Remove div255TruncNarrow(), rename div255RoundNarrow() to div255(). In practice we always want to round, and the narrowing to 8-bit is contextually obvious.
- Rename fastMulDiv255Round() approxMulDiv255() to stress it's approximate-ness over its speed. Drop Round for the same reason as above... we should always round.
- Add operator overloads so we don't have to keep throwing in seemingly-random Sk4px() or Sk4px::Wide() casts.
- use operator*() for 8-bit x 8-bit -> 16-bit math. It's always what we want, and there's generally no 8x8->8 alternative.
- MapFoo can take a const Func&. Don't think it makes a big difference, but nice to do.
BUG=skia:
Review URL: https://codereview.chromium.org/1202013002
This CL starts the process of pushing kLegacyFontHost_InitType-type SkSurfaceProps up the call stack and out of Skia. It:
Gets rid of the default SkBaseDevice ctor. This means everyone has to always hand an explicit SkSurfaceProps to it.
It makes public the SkBitmapDevice creation methods that require SkSurfaceProps.
Removes (in Skia's code base) all SkBitmapDevice ctor calls w/o SkSurfaceProps.
Makes the "recording" canvases (e.g., pdf, svg, xps) explicitly not use kLegacyFontHost_InitType.
Replicates the creating canvas/device's flags on saveLayer devices
BUG=skia:3934
Review URL: https://codereview.chromium.org/1204433002
sk_inv_determinant has a guard that the determinant can't get too big so this CL only checks if the determinant gets too small.
BUG=492263
Review URL: https://codereview.chromium.org/1188433011
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
When calling SkRegion::writeToMemory(NULL), it should return the same
number of bytes that it writes when calling
SkRegion::writeToMemory(buffer). Add a test to confirm this.
BUG=b/21271229
Review URL: https://codereview.chromium.org/1188293002
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
This fix is necessary to correctly propagate invalidations that
are external to skia. For example, when drawing video or WebGL
into a 2D canvas in Chrome, with mipmaps enabled.
BUG=crbug.com/498356
TEST=GrTextureMipMapInvalidationTest
Review URL: https://codereview.chromium.org/1177843007
Brings in the following functionality:
ARB_draw_instanced
ARB_instanced_arrays
NV_bindless_texture
EXT_direct_state_access
KHR_debug
Also cleans up some of the NVPR extension loading.
BUG=skia:
Review URL: https://codereview.chromium.org/1185573003
Adds a new FBO type kStencil_MSFBOType that is selected whenever
NV_framebuffer_mixed_samples extension is available. In this new
FBO type a non-msaa color buffer is created with a multisampled
stencil buffer attachment.
Replaces numSamples() with separate numColorSamples and numStencilSamples
methods in RenderTarget.
In mixed samples mode non-MSAA codepaths are used to draw simple shapes,
while NVPR-rendered paths and text are rendered with a multisampled
stencil.
BUG=skia:3177
Review URL: https://codereview.chromium.org/1001503002
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
I haven't figured out a pithy way to have these apply to only classes
originating from SkNx, so let's just remove them. There aren't too
many use cases, and it's not really any less readable without them.
Semantically, this is a no-op.
BUG=skia:
Review URL: https://codereview.chromium.org/1167153002
