Open jrmuizel opened 1 year ago
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);
}
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:
path
escapes into clip()
)
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.