Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
We don't need an explicit save-restore block to determine the bounds of
top-level control operations... the implicit save-restore that all
picutres have should logically work the same way.
The commented test failed before this and passes now.
Bug: skia:7735
Change-Id: Ibd31a3a9b0b48042ab3869a6bb57bc8d8bb78c09
Reviewed-on: https://skia-review.googlesource.com/126460
Commit-Queue: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
The values returned by SkCanvas::getDeviceClipBounds() are in the right
space, but have extra constraints on them that are not desirable for
bounding the logical bounds of draw operations:
- they are integral
- they are non-negative
We've been intersecting the bounds of each operation with these bounds,
which means we're mixing these bogus constraints into the bounds of each
recorded operation. This percolates up to the SkPicutre cull rect too.
The most egregious way to see the problem is to record a draw op
entirely in negative space... it'll come back with empty logical bounds
rather than its correct (negative-space) bounds. I've added a test
for this, and another test I also think should be passing but left
making it so as a follow up.
I've had to disable a couple tests asserting clips affect the bounds. :/
A possible follow-up might go back to using the clips to tighten the
bounds of the ops, just so long as we take the original user bounds and
map them with the CTM through to device space ourselves, rather than
relying on the recording canvas' clip stack. I think this means we'd
need to maintain our own stack of device-space float SkRect clip bounds
while calculating these op bounds.
Bug: skia:7735
Change-Id: I6bf15f6b2a9ba4329a4eeae7f9d57aa8729ec1bb
Reviewed-on: https://skia-review.googlesource.com/126002
Commit-Queue: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
works fine).
Change-Id: I3ed97cd7861e51dcb7cfa7950a97b420dbc6fbfb
TBR=reed@google.com
Reviewed-on: https://skia-review.googlesource.com/15143
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
This reverts commit 9ff301bf91.
Reason for revert: need to update G3, Flutter.
Original change's description:
> Remove SkLights include from SkCanvas.h
>
> SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
> works fine).
>
> Change-Id: Id2d7176eb3bf4609f72f46d513eebf59318f542f
> Reviewed-on: https://skia-review.googlesource.com/14904
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Florin Malita <fmalita@chromium.org>
>
TBR=mtklein@google.com,fmalita@chromium.org,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I4799ad5b31aaeaf529c8b912bbe09aa8869a5e6c
Reviewed-on: https://skia-review.googlesource.com/15107
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
works fine).
Change-Id: Id2d7176eb3bf4609f72f46d513eebf59318f542f
Reviewed-on: https://skia-review.googlesource.com/14904
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
When aspectRatio is not finite, insert() can fall into an infinite loop.
This happens if you pass SkRect::MakeLargest() to the factory as bounds.
BUG=skia:5974
Change-Id: Ibcc9e5c5943c718608d4c1448305f7b8f11413bc
Reviewed-on: https://skia-review.googlesource.com/11784
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This silences a new warning in clang 5.0
Change-Id: Ieb5b75a6ffed60107c3fd16075d2ecfd515b55e8
Reviewed-on: https://skia-review.googlesource.com/10006
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
This removes the SkRecords::Clear struct and everything that refers to it.
Notice there is nothing actually creating a Clear, which means this is all
dead code.
Now that all ops obey the clip, I don't think we need the weird
inflate-empty-to-epsilon hack for BBH queries.
BUG=skia:
Review URL: https://codereview.chromium.org/835813002
We fix this by rewriting empty queries to very tiny queries, which will certainly
hit ops that span the entire picture (like Clear) and hopefully not much more.
(This doesn't quite work in the full cull rect world if [0,0,ε,ε] doesn't
overlap the picture. Let's cross that bridge when we get there.)
BUG=432991
Review URL: https://codereview.chromium.org/732723004
