> 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.
Right. The way it was explained to me years ago that really stuck with me is that one way to implement call/cc is to copy the stack onto the heap.
(And another way to do it is to simply allocate all your function call frames on the heap to begin with and not have a stack. Then call/cc is essentially free, but you need a really good incremental garbage collector because now every function call conses.)
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.
That's a very interesting point. AFAICT, the Scheme standard doesn't actually say what should happen in this case. But here's what e.g. Chibi scheme does:
> 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.