> If we assumed a radially symmetric kernel, then coverage would just be some monotonic function of the distance from the pixel center to the edge
I don't think that's true. Consider a simple case where the shape is a square and you are sampling in such a way that the closest edge point is closer to a corner of the square than the filter width. Using a function of distance you will get the same result as when sampling far from the corner. But the coverage is different in the two cases.
Does copying the stack really work? What if some local variable changes in between the call/cc and calling the continuation? If the stack is a copy, that change will not be reflected when the continuation runs.
> But unfortunately, it is probably a billion users too late to start again from scratch.
A potentially interesting way around this is to make the client open source and get it shipped by all the Linux distributions. That would give application developers an initial audience which would help solve the chicken-and-egg problem.
That would be my take anyway. A big issue with Java is that it required installing a huge standard library - that should just be downloaded as required. And flash was never really intended for applications; it was always about "rich content". And Air (the application framework built on flash) has the problem that it's proprietary so you have to trust Adobe.
GTK+ uses the triangle technique along with a delay of 225 ms. When the pointer is inside the triangle, the delay is 1500 ms.
Firefox subscribes to the misguided "fake the look and feel of the default toolkit" idea, so on Linux it has a 225 ms delay, but without the triangle. Unfortunately 225 ms is way too short when there is no triangle.
A camera might produce a pixel by computing the average light input over a square, and in that sense you could consider the pixel itself a square.
But in signal processing you interpret it as a two step procedure: First, for every mathematical point of the scene, compute the average light input of the surrounding square to produce a band limited signal. Second, for every pixel report the value at the corresponding point in the band limited image.
The first step is filtering (in this case with a box filter), the second is point sampling.
I suspect there is some incoherent thinking about the BSD license. If you are a BSD advocate, consider this:
Someone takes a BSD project and bases a proprietary program on it. Is that person doing something wrong? Well, no, you say, because that's the whole point of the BSD license. It's also fine to keep rolling in new versions of the BSD project.
Now suppose someone takes a BSD project and relicenses it under the GPL, announces it on the internet, gets it into all the Linux distributions, and starts soliciting contributions of new GPL-only features while also rolling in new versions of the BSD project as they become available. Is that person doing something wrong?
I suspect that a calm, "No, that's also great. That's why we made it available under BSD." would not necessarily be the response.
There is a difference though: The IBM PC was the undisputed gold standard for compatibility. Software typically listed the hardware requirements as "IBM PC or 100% compatible". (Some non-IBM-compatible DOS hardware was sold, but it died out pretty quickly).
It doesn't look like there any similar gold standard is emerging for phones.
Very good comment, though broadcast and video are much harsher environments for graphics than a computer monitor. The resolution is lower as you point out, especially chroma resolution, and there may be interlacing and/or compression going on too. Each of these makes heavier blurring more desirable for high-frequency images such as text.
Regarding this:
So a controlled amount of blur, and I'm not talking about anti-aliasing,
it's worth pointing out that anti-aliasing is a form of blur, but most software usually uses a box filter which is a really a poor filter. I have some demonstration images here:
The first one is what cairo produces; the second is improved in three ways: (1) The antialiasing filter is based on the Jinc function rather than a box, (2) white and black are offset slightly from the top and bottom, and (3) the compositing is done in linear light, not sRGB.
The strokes in the second image are also somewhat wider in order to compensate for the lighter appearance that gamma-aware compositing produces.