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
morphology, blur.
[Reland with fixed tests.]
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
Reason for revert:
This CL is currently breaking the Win7 and Win8 bots on some of the new tests (in DM).
Original issue's description:
> Fix recursive computation of filter bounds for drop shadow,
> morphology, blur.
>
> Because we're computing "backwards" from a clip rect of destination
> pixels to be filled to the required source pixels, we should use tail
> recursion rather than head recursion in onFilterBounds().
>
> This actually only makes a difference for drop-shadow, where
> the computation is non-commutative. Blur and morphology commute, but I
> moved them to tail recursion anyway for clarity (so all onFilterBounds
> use tail recursion).
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/28648fe4a69b0cee8df42b5966e4e645c3aabefbR=bsalomon@google.com, senorblanco@chromium.orgTBR=bsalomon@google.com, senorblanco@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: djsollen@google.com
Review URL: https://codereview.chromium.org/504773003
morphology, blur.
Because we're computing "backwards" from a clip rect of destination
pixels to be filled to the required source pixels, we should use tail
recursion rather than head recursion in onFilterBounds().
This actually only makes a difference for drop-shadow, where
the computation is non-commutative. Blur and morphology commute, but I
moved them to tail recursion anyway for clarity (so all onFilterBounds
use tail recursion).
BUG=skia:
R=bsalomon@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/481273005
In SkBBoxHierarchyRecord:
Since the bounds we pass to saveLayer are in the pre-filtering
coordinate space, they aren't correct for determining the actual
device pixels touched by the saveLayer in this case.
The easiest fix for now is to pass the clip bounds, since the final
draw done in restore() will never draw outside the clip.
In SkRecordDraw:
We do adjust the bounds passed to saveLayer, so we just need to make
sure that when we're using a paint that may affect transparent black,
we ignore the calculated bounds of draw ops and use the clip intersected
with those adjusted bounds.
See originally crrev.com/497773002
BUG=skia:
R=reed@google.com, senorblanco@chromium.org, junov@chromium.org, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/496963003
The only substantive change in this CL is skipping atlasing
for any layers that are involved in nesting. Prior versions
have allowed nesting layers to be atlased.
--------------------------------------------------------
All times are on Windows with a repeat count of 200.
Format is: <time in ms> (<# of glBindframebuffer calls>)
How to interpret this:
For the boogie page:
both columns should be the same (since boogie has no
nested layers)
without the new API the tiled case doesn't show any real
benefit from hoisting
For the carsvg page:
The nesting change does increase the number of FBO
switches but doesn't kill performance
Because of the location & size of the layers the
tile case does show some improvement (even
without the new API)
boogie
-------
w/o nested change w/ nested change
simple 5.62 (811) N/A
tiled 7.72 (811) N/A
simple w/ hoisting 5.23 (409) 5.77 (409)
(but no caching)
tiled w/ hoisting 7.57 (809) 7.49 (809)
(but no caching)
carsvg
------
w/o nested change w/ nested change
simple 60.37 (141990) N/A
tiled 115.13 (256929) N/A
simple w/ hoisting 41.57 (64570) 42.82 (72279)
(but no caching)
tiled w/ hoisting 84.24 (154352) 84.71 (165630)
(but no caching)
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/476833004
- Remove SkData double-unref to fix assert.
- Re-enable the test with DEBUG (was disabled due to double-unref assert).
- SkRandom instead of rand() for thread-safety.
- General clean up of the test for readability.
Motivation: I am investigating turning on SkFlate::HaveFlate on Windows.
R=mtklein@google.com
Author: halcanary@google.com
Review URL: https://codereview.chromium.org/464333002
Extreme implicit quartic equations solve to roots that are different
enough that they appear to have failed. In this case, fall back on
binary searching to find an intersection.
Relax the condition when this happens; don't give up just because the
computed implicit root points aren't remotely the same.
TBR=reed
BUG=skia:2808
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/456383003
For now this only creates a degenerate bounding box hierarchy where all ops
just have maximal bounds. I will flesh out FillBounds in future CL(s).
Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even
looked at the diffs yet---so I've disabled those test modes for now. RTree
seems fine, so that'll at least get us coverage for all this new plumbing.
BUG=skia:
R=robertphillips@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/454123003
The recorder optimizer's pattern matcher was accepting command sequences
when it shouldn't have.
In the submitted case, and the pattern matcher was looking for:
saveLayer, drawBitmap, restore
and in the rendering for the submitted case, the sequence of commands
were:
saveLayer, drawBitmap, drawBitmap, restore
This sequence was improperly accepted by the matcher, and the optimizer
reduced the sequence to:
drawBitmap, drawBitmap
where the opacity from the saveLayer paint argument was applied
to the first drawBitmap only.
The user-visible effect in Chrome was a flashing effect on an image
caused by incorrect (too-high) opacity.
The patch adds a Skia test to check for pixel colour values in
a similarly structured recording. All other Skia tests pass.
Blink layout tests also pass with this change.
BUG=chromium:344987
R=robertphillips@google.com, reed@google.com, mtklein@google.com
Author: dneto@chromium.org
Review URL: https://codereview.chromium.org/430503004
Add a unique ID to SkImageFilter, and use it as part
of a persistent cache of image-filtered results. This is used for
caching frame-to-frame coherent filters.
We also keep track of which filter subtrees do not reference the
src input, and use a GenID of zero for the src input in that case.
That way, subtrees which are not dependent on the filter input can be
cached independently of it.
This gives approximately a 4X speedup on
letmespellitoutforyou.com/samples/svg/filter_terrain.svg on Z620
and Nexus10. The cache key consists of the uniqueID of the filter, the
clip bounds, the CTM and the genID of the input bitmap.
Since this does not yet handle the case where the input primitives
(and part of the resulting filter tree) are unchanged, we have
to keep around the external cache for that painting case.
When the work to cache unchanging input primitives is done, the
old cache can be removed, and the new UniqueIDCache will be renamed
to Cache.
R=bsalomon@google.com, mtklein@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/414483003
https://codereview.chromium.org/283093002 fixed some bugs in pipe memory
allocation, but also introduced one of its own: nearly every block requested
from needOpBytes() got its own 16K allocation.
The correct logic is to take the requested size, add four more bytes for a
DrawOp, make sure that's 4-byte aligned, then check to see if there's enough
space for that in the current block. If there's not, allocate at least
MIN_BLOCK_SIZE bytes to fit the request.
The bug is that I moved that round-up-to-MIN_BLOCK_SIZE step before checking
for space in the current block. This means most (all?) blocks will be 16K but
never seem to have room to fit another allocation. You need 8 bytes? You get
16K. You need 8 more bytes? Nope, can't fit that. Here's a new 16K...
This reverts the change to the test I made then, which really should have
tipped me off. It was testing exactly this bug.
BUG=372671
R=tomhudson@chromium.org, tomhudson@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/433463003
Refactor CanvasStateTest to pull out functions which can
either be called directly or from a shared library. Add a
command line flag to pass in the path to a library to open
to call those functions from.
Separate different CanvasTest tests into separate DEF_TEST
tests. This allows them to be run in parallel.
Move the ifdefs outside of function declarations to skip
running CanvasTest tests which do nothing.
Add the canvas_state_lib target. It is a shared library that
exports some functions to be called by another version of
Skia.
BUG=b/15693384
R=djsollen@google.com, reed@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/400043003
Share command flags between dm and unit tests.
Also, allow dm's core to be included by itself and iOSShell.
Command line flags that are the same (or nearly the same) in DM
and in skia_tests have been moved to common_flags. Authors,
please check to see that the shared common flag is correct for
the tool.
For iOS, the 'tool_main' entry point has a wrapper to allow multiple
tools to be statically linked in the iOSShell.
Since SkCommandLineFlags::Parse can only be called once, these calls
are disabled in the IOS build.
Since the iOS app directory is dynamically assigned a name, use '@' to
select it. (This is the same convention chosen by the Mobile Harness
iOS file system utilities.)
Move the heart of dm.gyp into dm.gypi so that it can be included by
itself and iOSShell.gyp.
Add tools/flags/SkCommonFlags.* to define and declare common
command line flags.
Add support for dm to iOSShell.
BUG=skia:
R=scroggo@google.com, mtklein@google.com, jvanverth@google.com, bsalomon@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/389653004
Fixes Android framework build.
When building for the Android framework, we depend on SkUserConfig.h
to define things like SK_SUPPORT_GPU. So we cannot have the first
include inside a guard requring SK_SUPPORT_GPU to be defined. Include
SkTypes first, which will pull in SkUserConfig, define the flag, and
allow us to include GrContextFactory.h.
R=reed@google.com, djsollen@google.com
Author: scroggo@google.com
Review URL: https://codereview.chromium.org/394533003
skia_ios.mm
Get the app's Documents directory and pass use it to set the resource path.
This is a quick hack which will be replaced by a new application that is
a tiny shim around a command line tool.
SkImageEncoder.h
SkForceLinking.cpp
SkImageDecoder_CG.cpp
Add support for FORCE_LINKING so iOS sees the PNG encoder and others.
SkFloatBits.cpp
SkPoint.cpp
Handle denormalized numbers that are floored by the iOS ARM processor.
SkImageDecoder_iOS.mm
Remove empty encoder factory.
SkTouchGesture.cpp
Return early on empty state on touch rather than aborting (crashing)
JpegTest.cpp
Hal via stackoverflow.com says partial jpegs can be gray as well.
skia_test.cpp
Remove crash handler call for now to avoid link failure.
OverwriteLine.h
Remove fancy line overwrite for iOS.
Resources.cpp
Add interface to set resource directory based on runtime query.
BUG=skia:2736 skia:2737 skia:2738
R=reed@google.com, halcanary@google.com, mtklein@google.com, tfarina@chromium.org
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/373383003
When building acceleration structures for SkPicture, we must transform
the primitive's bounds not only by its own SkPaint, but by the paints of
any saveLayer()s currently active above it.
We do this by pushing the SkPaint onto a stack on
saveLayer(), and popping them on restore(). We also push
a NULL paint in save(), so that the pushes and pops are
balanced.
BUG=skia:2734
R=mtklein@google.com, reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/380373003
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
