AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
6927ab9311
skia2/gm/crbug_224618.cpp

119 lines
4.4 KiB
C++
Raw Normal View History

Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
/*
* Copyright 2020 Google LLC
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
#include "gm/gm.h"
#include "include/core/SkCanvas.h"
#include "include/core/SkColor.h"
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
#include "include/core/SkImage.h"
switch to SkM44 Change-Id: I2d44eb5b1984212fb461977f5e9ee95717046a8e Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272467 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
2020-02-21 16:19:20 +00:00
#include "include/core/SkM44.h"
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
#include "include/core/SkMatrix.h"
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
#include "include/core/SkSurface.h"
#include "include/effects/SkGradientShader.h"
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
#include "tools/timer/TimeUtils.h"
// Adapted from https://codepen.io/adamdupuis/pen/qLYzqB
class CrBug224618GM : public skiagm::GM {
public:
CrBug224618GM() : fTime(0.f) {}
protected:
SkString onShortName() override {
return SkString("crbug_224618");
}
SkISize onISize() override {
return SkISize::Make(kMaxVW, kMaxVW);
}
// This animates the FOV in viewer, to ensure the panorama covering rects are stable across
// a variety of perspective matrices
bool onAnimate(double nanos) override {
fTime = TimeUtils::Scaled(1e-9f * nanos, 0.5f);
return true;
}
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
void onOnceBeforeDraw() override {
static const SkColor kColors[2] = {SK_ColorTRANSPARENT, SkColorSetARGB(128, 255, 255, 255)};
sk_sp<SkShader> gradient = SkGradientShader::MakeRadial(
{200.f, 200.f}, 25.f, kColors, nullptr, 2, SkTileMode::kMirror,
SkGradientShader::kInterpolateColorsInPremul_Flag, nullptr);
sk_sp<SkSurface> surface = SkSurface::MakeRasterN32Premul(400, 400);
SkPaint bgPaint;
bgPaint.setShader(gradient);
surface->getCanvas()->drawPaint(bgPaint);
fCubeImage = surface->makeImageSnapshot();
}
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
void onDraw(SkCanvas* canvas) override {
SkScalar viewportWidth = SkScalarMod(fTime, 10.f) / 10.f * (kMaxVW - kMinVW) + kMinVW;
SkScalar radius = viewportWidth / 2.f; // round?
// See https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/perspective
SkM44 proj{1.f, 0.f, 0.f, 0.f,
0.f, 1.f, 0.f, 0.f,
0.f, 0.f, 1.f, 0.f,
0.f, 0.f, -1.f / radius, 1.f};
SkM44 zoom = SkM44::Translate(0.f, 0.f, radius);
SkM44 postZoom = SkM44::Translate(0.f, 0.f, -radius - 1.f);
switch to SkM44 Change-Id: I2d44eb5b1984212fb461977f5e9ee95717046a8e Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272467 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
2020-02-21 16:19:20 +00:00
SkM44 rotateHorizontal = SkM44::Rotate({0, 1, 0}, 2.356194490192345f);
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
// w in degrees will need to be converted to radians
SkV4 axisAngles[6] = {
{0.f, 1.f, 0.f, -90.f}, // rotateY(-90deg)
{1.f, 0.f, 0.f, 0.f}, // <none>
{0.f, 1.f, 0.f, 90.f}, // rotateY(90deg)
{0.f, 1.f, 0.f, 180.f}, // rotateY(180deg)
{1.f, 0.f, 0.f, -90.f}, // rotateX(-90deg)
{1.f, 0.f, 0.f, 90.f}, // rotateX(90deg)
};
SkColor faceColors[6] = {
SK_ColorRED,
SK_ColorGREEN,
SK_ColorBLUE,
SK_ColorYELLOW,
SkColorSetARGB(0xFF, 0xFF, 0xA5, 0x00), // orange css
SkColorSetARGB(0xFF, 0x80, 0x00, 0x80) // purple css
};
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
for (int i = 0; i < 6; ++i) {
switch to SkM44 Change-Id: I2d44eb5b1984212fb461977f5e9ee95717046a8e Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272467 Reviewed-by: Florin Malita <fmalita@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
2020-02-21 16:19:20 +00:00
SkM44 model = SkM44::Rotate({axisAngles[i].x, axisAngles[i].y, axisAngles[i].z},
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
SkDegreesToRadians(axisAngles[i].w));
model = SkM44::Translate(radius, radius) * proj * // project and place content
zoom * rotateHorizontal * model * postZoom * // main model matrix
SkM44::Translate(-radius, -radius); // center content
canvas->save();
clean up public m44 and camera api saveCamera() is no longer experimental In a separate CL, will stage changes to concat virtual to take M44. Change-Id: Iaf37ce2f24ab1223c54aeb1e79eaebf18f87fece Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281589 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Reed <reed@google.com>
2020-04-06 14:41:09 +00:00
canvas->concat(model);
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
SkPaint fillPaint;
fillPaint.setAntiAlias(true);
fillPaint.setColor(faceColors[i]);
Move more Ops to skgpu::v1 namespace GrFillRRectOp GrFillRectOp Bug: skia:11837 Change-Id: Icdecc2ccd9def659b0d9402910b2072e02577a66 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/444817 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Robert Phillips <robertphillips@google.com>
2021-09-01 20:31:34 +00:00
// Leverages FillRectOp on GPU backend
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
canvas->drawRect(SkRect::MakeWH(viewportWidth, viewportWidth), fillPaint);
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
Move more Ops to skgpu::v1 namespace GrFillRRectOp GrFillRectOp Bug: skia:11837 Change-Id: Icdecc2ccd9def659b0d9402910b2072e02577a66 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/444817 Reviewed-by: Michael Ludwig <michaelludwig@google.com> Commit-Queue: Robert Phillips <robertphillips@google.com>
2021-09-01 20:31:34 +00:00
// Leverages TextureOp on GPU backend, to ensure sure both quad paths handle clipping
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
canvas->drawImageRect(fCubeImage.get(),
SkRect::MakeWH(fCubeImage->width(), fCubeImage->height()),
More hiding of legacy drawImage calls Also cleanup some of the duplicate code in SkRecords Bug: skia:7650 Change-Id: I4d3167a892c126c19a54002beab25c9a6c96fa5d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357000 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
2021-01-22 03:25:21 +00:00
SkRect::MakeWH(viewportWidth, viewportWidth),
SkSamplingOptions(SkFilterMode::kLinear), &fillPaint,
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
SkCanvas::kFast_SrcRectConstraint);
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
canvas->restore();
}
}
private:
static const int kMaxVW = 800;
static const int kMinVW = 300;
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
SkScalar fTime;
Add ClipToW0 utility function for GrQuads, and improve perspective handling in rest of quad pipeline This function produces 0, 1, or 2 quads clipped to w > 0, with proper local coords. To make its signature a little easier to reason about, I added a simple 'DrawQuad' struct that represents the combination of device and local coordinates, and edge AA flags. I am open to suggestions for the name. GrQuad::bounds() remains perspective aware so that it is always correct. I updated CropToRect to check for w < 0 and not attempt to crop in that scenario. Theoretically, we could clip to w = 0 first and then go through the CropToRect optimization path. However, with the current state of the GrFillRectOp and GrTextureOp, that made it more annoying to have the bulk APIs handle the w clipping as well. So for now, the w plane clipping is entirely the responsibility of the ops. A benefit of this approach is that GrRenderTargetContext doesn't need to be modified, and in the case where the clipping produces 2 quads they are automatically put in the same op w/o going through any batching code. However, it is becoming clear to me that managing 4 effective code paths (fill + texture X simple + bulk API) is more maintenance than it's worth. I added skbug:9869 to work out how to simplify these op creation APIs further, and if we succeed there, I think it will make applying the W plane clipping more convenient as well. For now, since this affects SkiaRenderer on Linux stable, I am pushing for correctness. Bug: skia:9779, chromium:224618 Change-Id: I4218a956cbe0bbc2b5c9cf133a069d54c93848e8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268686 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-02-07 15:14:45 +00:00
sk_sp<SkImage> fCubeImage;
Add GM reproducing perspective failures Modeled on https://codepen.io/adamdupuis/pen/qLYzqB, this GM creates a cube of rectangles with the camera at the center. It animates the FOV since the original chrome issue was most visible when resizing the page (which then updated the fov of the perspective css transform). This draws correctly with the raster backend. There are two issues it causes with Ganesh: 1. The input coordinates of some of the cube faces have 0 or negative ws. - When negative, the current bounds code does not perform clipping and just uses the mirrored point, which leads to misleading bounds. - When 0, the current bounds code produces infinities, and then GrOpsTask discards the op with non-finite bounds. 2. The anti-aliasing code also ignores w <= 0, and so all of its screen space math is incorrect. This causes a mix of completely discarded draws and distorted draws on the GPU backend. Bug: skia:9779, chromium:224618 Change-Id: Ib00b909f51cbf7aaba5b89ed830ddc720ad3c73d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265763 Commit-Queue: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Jim Van Verth <jvanverth@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com>
2020-01-22 19:32:11 +00:00
};
DEF_GM(return new CrBug224618GM();)
Reference in New Issue Copy Permalink