Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add clipRect() function #33

Open
jrmuizel opened this issue Dec 9, 2022 · 2 comments
Open

add clipRect() function #33

jrmuizel opened this issue Dec 9, 2022 · 2 comments

Comments

@jrmuizel
Copy link

jrmuizel commented Dec 9, 2022

Clipping to integer pixel axis aligned rects has a very different implementation than arbitrary geometry. It would be nice to be able to expose ctx.clipRect() instead ofctx.rect(); ctx.clip();

Skia and CoreGraphics both expose a clipRect() type function so there's definitely precedence for this kind of thing.

@Kaiido
Copy link

Kaiido commented Dec 12, 2022

Clipping to integer pixel axis aligned rects has a very different implementation than arbitrary geometry.

Is the idea that this method would only allow integer coords, and wouldn't be affected by the context's CTM, like getImageData and putImageData do?
If so, that naming sounds too close to fillRect() and strokeRect() which are affected by the current CTM and can be drawn at non integer coordinates.

From what I can tell, Skia's and CoreGraphics's versions also are affected by the context's transform and both accept floating point coords for their rect param.

If there is indeed a very different implementation for "integer pixel axis aligned rects", and assuming it's more performant, shouldn't this be part of an implementation's optimizations rather than a new method on the already "well-stocked" API?

Looking a bit on the internets, it seems that ctx.rect(...); ctx.clip(); was somehow confusing to some web-devs who forgot to call beginPath(), but I believe the Path2D interface solves this issue, and if one really wants a fillRect() version of clip() they could write one really easily, so I'm not entirely sure there would be much benefit for such a method.

function clipRect(ctx, x, y, w, h) {
  const path = new Path2D();
  path.rect(x, y, w, h);
  ctx.clip(path);
}

@jrmuizel
Copy link
Author

The proposed function would have the same semantics as:

function clipRect(ctx, x, y, w, h) {
  const path = new Path2D();
  path.rect(x, y, w, h);
  ctx.clip(path);
}

The advantage is that it's more performant than the more general JS implementation:

  1. It avoids the object allocation (it's unlikely escape analysis would be able to do this because path escapes into clip())
  2. It avoids having to do rectangle detection on the path: https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/gfx/skia/skia/src/core/SkPath.cpp#3562
  3. It gives more predictable performance. Firefox doesn't currently detect and fast path clipping to a rectangle when using Direct2D for canvas on Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants