2014-08-06 20:07:15 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2014 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "gm/gm.h"
|
2019-05-01 21:28:53 +00:00
|
|
|
#include "include/core/SkCanvas.h"
|
|
|
|
#include "include/core/SkColor.h"
|
|
|
|
#include "include/core/SkMatrix.h"
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "include/core/SkPaint.h"
|
|
|
|
#include "include/core/SkPicture.h"
|
|
|
|
#include "include/core/SkPictureRecorder.h"
|
2019-05-01 21:28:53 +00:00
|
|
|
#include "include/core/SkPoint.h"
|
|
|
|
#include "include/core/SkRect.h"
|
|
|
|
#include "include/core/SkRefCnt.h"
|
|
|
|
#include "include/core/SkScalar.h"
|
2019-04-23 17:05:21 +00:00
|
|
|
#include "include/core/SkShader.h"
|
2019-05-01 21:28:53 +00:00
|
|
|
#include "include/core/SkSize.h"
|
|
|
|
#include "include/core/SkString.h"
|
|
|
|
#include "include/core/SkTileMode.h"
|
|
|
|
#include "include/core/SkTypes.h"
|
2014-08-06 20:07:15 +00:00
|
|
|
|
2016-09-01 18:24:54 +00:00
|
|
|
constexpr SkScalar kPictureSize = SK_Scalar1;
|
|
|
|
constexpr SkScalar kFillSize = 100;
|
|
|
|
constexpr unsigned kRowSize = 6;
|
2014-08-06 20:07:15 +00:00
|
|
|
|
2016-09-01 18:24:54 +00:00
|
|
|
constexpr struct {
|
2014-08-06 20:07:15 +00:00
|
|
|
SkScalar x, y, w, h;
|
|
|
|
SkScalar offsetX, offsetY;
|
|
|
|
} tiles[] = {
|
|
|
|
{ 0, 0, 1, 1, 0, 0 },
|
|
|
|
{ -0.5f, -0.5f, 1, 1, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1, 1, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1.5f, 1.5f, 0, 0 },
|
|
|
|
{ -0.5f, -0.5f, 1.5f, 1.5f, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1.5f, 1.5f, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 0.5f, 0.5f, 0, 0 },
|
|
|
|
{ 0.25f, 0.25f, 0.5f, 0.5f, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ -0.25f, -0.25f, 0.5f, 0.5f, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1, 1, 0.5f, 0.5f },
|
|
|
|
{ -0.5f, -0.5f, 1, 1, 0.5f, 0.5f },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1, 1, 0.5f, 0.5f },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1.5f, 1.5f, 0.5f, 0.5f },
|
|
|
|
{ -0.5f, -0.5f, 1.5f, 1.5f, 0.5f, 0.5f },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1.5f, 1.5f, 0.5f, 0.5f },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1.5f, 1, 0, 0 },
|
|
|
|
{ -0.5f, -0.5f, 1.5f, 1, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1.5f, 1, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 0.5f, 1, 0, 0 },
|
|
|
|
{ 0.25f, 0.25f, 0.5f, 1, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ -0.25f, -0.25f, 0.5f, 1, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1, 1.5f, 0, 0 },
|
|
|
|
{ -0.5f, -0.5f, 1, 1.5f, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ 0.5f, 0.5f, 1, 1.5f, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
|
|
|
|
{ 0, 0, 1, 0.5f, 0, 0 },
|
|
|
|
{ 0.25f, 0.25f, 1, 0.5f, 0, 0 },
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
{ -0.25f, -0.25f, 1, 0.5f, 0, 0 },
|
2014-08-06 20:07:15 +00:00
|
|
|
};
|
|
|
|
|
2014-12-09 13:23:20 +00:00
|
|
|
static void draw_scene(SkCanvas* canvas, SkScalar pictureSize) {
|
|
|
|
canvas->clear(SK_ColorWHITE);
|
|
|
|
|
|
|
|
SkPaint paint;
|
|
|
|
paint.setColor(SK_ColorGREEN);
|
|
|
|
paint.setStyle(SkPaint::kFill_Style);
|
|
|
|
paint.setAntiAlias(true);
|
|
|
|
|
|
|
|
canvas->drawCircle(pictureSize / 4, pictureSize / 4, pictureSize / 4, paint);
|
|
|
|
canvas->drawRect(SkRect::MakeXYWH(pictureSize / 2, pictureSize / 2,
|
|
|
|
pictureSize / 2, pictureSize / 2), paint);
|
|
|
|
|
|
|
|
paint.setColor(SK_ColorRED);
|
|
|
|
canvas->drawLine(pictureSize / 2, pictureSize * 1 / 3,
|
|
|
|
pictureSize / 2, pictureSize * 2 / 3, paint);
|
|
|
|
canvas->drawLine(pictureSize * 1 / 3, pictureSize / 2,
|
|
|
|
pictureSize * 2 / 3, pictureSize / 2, paint);
|
|
|
|
|
|
|
|
paint.setColor(SK_ColorBLACK);
|
|
|
|
paint.setStyle(SkPaint::kStroke_Style);
|
|
|
|
canvas->drawRect(SkRect::MakeWH(pictureSize, pictureSize), paint);
|
|
|
|
}
|
|
|
|
|
2014-08-06 20:07:15 +00:00
|
|
|
class PictureShaderTileGM : public skiagm::GM {
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
protected:
|
|
|
|
|
2015-03-26 01:17:31 +00:00
|
|
|
SkString onShortName() override {
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
return SkString("pictureshadertile");
|
|
|
|
}
|
|
|
|
|
2015-03-26 01:17:31 +00:00
|
|
|
SkISize onISize() override {
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
return SkISize::Make(800, 600);
|
|
|
|
}
|
|
|
|
|
2015-03-26 01:17:31 +00:00
|
|
|
void onOnceBeforeDraw() override {
|
2014-08-06 20:07:15 +00:00
|
|
|
SkPictureRecorder recorder;
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
SkCanvas* pictureCanvas = recorder.beginRecording(kPictureSize, kPictureSize);
|
2014-12-09 13:23:20 +00:00
|
|
|
draw_scene(pictureCanvas, kPictureSize);
|
2016-03-18 14:25:55 +00:00
|
|
|
sk_sp<SkPicture> picture(recorder.finishRecordingAsPicture());
|
2014-08-06 20:07:15 +00:00
|
|
|
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
SkPoint offset = SkPoint::Make(100, 100);
|
|
|
|
pictureCanvas = recorder.beginRecording(SkRect::MakeXYWH(offset.x(), offset.y(),
|
|
|
|
kPictureSize, kPictureSize));
|
|
|
|
pictureCanvas->translate(offset.x(), offset.y());
|
2014-12-09 13:23:20 +00:00
|
|
|
draw_scene(pictureCanvas, kPictureSize);
|
2016-03-18 14:25:55 +00:00
|
|
|
sk_sp<SkPicture> offsetPicture(recorder.finishRecordingAsPicture());
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
|
2014-08-06 20:07:15 +00:00
|
|
|
for (unsigned i = 0; i < SK_ARRAY_COUNT(tiles); ++i) {
|
|
|
|
SkRect tile = SkRect::MakeXYWH(tiles[i].x * kPictureSize,
|
|
|
|
tiles[i].y * kPictureSize,
|
|
|
|
tiles[i].w * kPictureSize,
|
|
|
|
tiles[i].h * kPictureSize);
|
|
|
|
SkMatrix localMatrix;
|
|
|
|
localMatrix.setTranslate(tiles[i].offsetX * kPictureSize,
|
|
|
|
tiles[i].offsetY * kPictureSize);
|
|
|
|
localMatrix.postScale(kFillSize / (2 * kPictureSize),
|
|
|
|
kFillSize / (2 * kPictureSize));
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
|
2016-03-13 21:13:58 +00:00
|
|
|
sk_sp<SkPicture> pictureRef = picture;
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
SkRect* tilePtr = &tile;
|
|
|
|
|
|
|
|
if (tile == SkRect::MakeWH(kPictureSize, kPictureSize)) {
|
|
|
|
// When the tile == picture bounds, exercise the picture + offset path.
|
2016-03-13 21:13:58 +00:00
|
|
|
pictureRef = offsetPicture;
|
2015-08-27 14:41:13 +00:00
|
|
|
tilePtr = nullptr;
|
Tweak SkPictureShader's tile semantics.
Currently, the tile offset is added when drawing the picture. This might
have made a tiny bit of sense when the picture was always positioned at
origin, but with a picture cull rect offset things looks really strange.
For example, to specify a tile == the picture cull rect we have to pass
in [-cullrect.x, -cullrect.y, cullrect.width, cullrect.height]. Yikes.
(there's also a bug when not passing a tile, as we use a default tile
== cullrect but don't compensate for the above oddity)
This changes the semantics of the tile offset: it is now subtracted when
drawing the picture tile. As a consequence, one can pass in a tile equal
to the cull rect and get the expected behavior (same when not passing
a tile).
This will require a minor Blink change with the roll, as one client
works around the current behavior:
https://codereview.chromium.org/789503003
R=reed@google.com,robertphillips@google.com
BUG=440046
Review URL: https://codereview.chromium.org/733203005
2014-12-08 19:13:27 +00:00
|
|
|
}
|
|
|
|
|
2019-04-03 14:27:45 +00:00
|
|
|
fShaders[i] = pictureRef->makeShader(SkTileMode::kRepeat, SkTileMode::kRepeat,
|
|
|
|
&localMatrix, tilePtr);
|
2014-08-06 20:07:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-26 01:17:31 +00:00
|
|
|
void onDraw(SkCanvas* canvas) override {
|
2014-08-06 20:07:15 +00:00
|
|
|
canvas->clear(SK_ColorBLACK);
|
|
|
|
|
|
|
|
SkPaint paint;
|
|
|
|
paint.setStyle(SkPaint::kFill_Style);
|
|
|
|
|
|
|
|
for (unsigned i = 0; i < SK_ARRAY_COUNT(fShaders); ++i) {
|
|
|
|
paint.setShader(fShaders[i]);
|
|
|
|
|
|
|
|
canvas->save();
|
|
|
|
canvas->translate((i % kRowSize) * kFillSize * 1.1f,
|
|
|
|
(i / kRowSize) * kFillSize * 1.1f);
|
|
|
|
canvas->drawRect(SkRect::MakeWH(kFillSize, kFillSize), paint);
|
|
|
|
canvas->restore();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2016-03-13 21:13:58 +00:00
|
|
|
sk_sp<SkShader> fShaders[SK_ARRAY_COUNT(tiles)];
|
2014-08-06 20:07:15 +00:00
|
|
|
|
2020-09-03 02:42:33 +00:00
|
|
|
using INHERITED = GM;
|
2014-08-06 20:07:15 +00:00
|
|
|
};
|
|
|
|
|
2015-08-26 20:07:48 +00:00
|
|
|
DEF_GM(return new PictureShaderTileGM;)
|