Are you saying that HTML Canvas should not have a method to draw circles because you can implement a circle drawing algorithm in JavaScript?

What is your point? That it's a liability that PostScript has a far superior, more powerful, scalable, device independent, future proof, and vastly more convenient and easier to use and understand imaging model than X11?

And by the way, NeWS eyes came first: "xeyes" was a lower quality knock-off, not the original. The first version of "xeyes" actually used a rectangular window, which kind of missed the whole point, until somebody added hundreds of lines of extremely complex code to implement the SHAPE extension. I linked to the source above: download and read it if you don't believe me.

NeWS lets you shape a round (or any shape) window the exact same way you draw the same shape. See how pizzatool shapes the spinning full or half circle pizza window floating inside a rectangular frame, so you can easily move and resize it:

% Reshape the parent popup pizza window,
% to reflect a change in the pizza's shape.
% In all truth, the pizza canvas is rectangular!
% It gets its round (or semi-circular) shape
% from the shape of its parent canvas,
% which is a hollow rectangular popup window frame
% (just the window borders),
% with a discontiguous pie floating in the center.
%
/ReshapeParent { % - => -
gsave
Parent setcanvas
/bbox PreviewWindow send /reshape PreviewWindow send
grestore
} def

% The popup pizza window path includes the window borders and the
% round (or semi-circular) pie floating in the middle, but excludes
% everything between.
%
/path { % x y w h => -
matrix currentmatrix 5 1 roll	% mat x y w h
/minsize self send xymax
4 2 roll translate	% mat w h
0 0 3 index 3 index rectpath
WInset SInset translate	% mat w h
EInset WInset add	% mat w h ewinsets
NInset SInset add	% mat w h ewinsets nsinsets
xysub	% mat insidew insideh
0 0 3 index 3 index rectpath

2 div exch 2 div exch	% mat centerx centery

2 copy translate
min dup neg scale	% mat

{ % send to Center client (the Pizza):
/radiusscale self send 0 moveto
0 0 /radiusscale self send
0 360 /fraction self send mul
arc closepath
}	% mat {msg}
/Center /client self send	% ... client true | false
/WhatPizza? assert	% mat {msg} client
send	% mat
setmatrix	%
} def

% Reshape the window canvas with the even/odd rule.
%
/reshape { % x y w h => -
/invalidate self send
gsave
4 2 roll translate	% w h
0 0 4 2 roll	% 0 0 w h
/path self send	%
self eoreshapecanvas
grestore
} def

So it looks like this:

https://donhopkins.com/home/catalog/images/pizzatool.gif

But with X-Windows you have to bend over backwards manipulating pixmaps or lists of rectangles, so the window shaping code is completely different and much more complex than the drawing code.

Case in point: take a look at the "ShapePieMenu" function in the Tk pie menus I implemented for X11/TCL/Tk SimCity, for another example of how much of a pain in the ass it is to shape a window in X11. It has to first get the display and query to make sure the extension is supported, then if it is, make the window exist, get the window id, make a pixmap, make a graphics context, set the foreground color, erase the background, set the foreground color, fill a bunch of rectangles, free the graphics context, and call XShapeCombineMask. And that's only shaping the window to a simple list of few rectangles for all the labels, not a circle, which would have been MUCH harder:

https://github.com/SimHacker/micropolis/blob/master/micropol...

So funny that you'd compare drawing circles in X11 -vs- PostScript. Have you actually tried to draw a circle with either API yourself -- let alone used the X11 SHAPE extension to make a round window? Here's an excerpt from the X-Windows Disaster which addresses that very topic -- specifically "in the case of arcs":

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

Myth: X is “Device Independent”

X is extremely device dependent because all X graphics are specified in pixel coordinates. graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don’t mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.

A task as simple as filing and stroking shapes is quite complicated because of X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus pixels” when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that “in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion).” This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can’t even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.