[racket-dev] Caching rendered icons

On 01/13/2012 06:16 PM, Robby Findler wrote:
> On Fri, Jan 13, 2012 at 7:09 PM, Neil Toronto<neil.toronto at gmail.com>  wrote:
>> I agree with everybody, especially Sam. :)
>>
>> We're supposed to have a rich compiler extension API, in which programs
>> evaluated at expansion time are just as capable as runtime programs.
>> Further, "building Racket" means "expanding Racket code fully" which means
>> "running Racket code," so the build environment should be the same as the
>> runtime. Ideally, we would get these servers up to snuff.
>>
>> I can see how we might need to make concessions, though, so I'm willing to
>> toss my elegant solution (*sniff*) and go with runtime rendering and
>> caching.
>
> I think that, in the worst case, we should only go with runtime
> rendering when cairo isn't available at compile time.

I have two problems with this. One of them I also have with Eli's 
suggestion: we'd end up with Racket distributions that have different 
performance characteristics depending on where they were compiled.

To make the point better, we'll take the PLT logo I've been working on 
as an example. (Require `images/logos' and do `(plt-logo 256)' to see 
it.) The 256x256 logo takes 1.3 seconds to render on my computer; I can 
imagine it taking 2-5 on others.

I would rather have everyone pay 2-5 seconds once than have a percentage 
of people pay 2-5 seconds every time they start DrRacket because they 
happened to get the build from a server that didn't have Cairo installed.

(The example is rather contrived, since the logo would probably be 
"cached" by hand. But the point stands.)

My other problem with falling back to runtime rendering is that either 
1) user code would have to compute every value they use to make icons 
both normally and for-syntax; or 2) I would have to break the nice 
abstraction I have now (wherein `compiled-bitmap' needs to know nothing 
about its inner expression) and serialize the arguments to the 
icon-constructing functions at compile-time and deserialize them at 
runtime. Option #1 sounds bad for the user - it would be easy to have 
icons that render differently depending on whether they were done at 
compile time or run time. Option #2 bothers me for a reason I can't 
quite explain.

Eli's suggestion has me writing macros that act like functions, except 
that they parse the syntax of arguments and sometimes can run at compile 
time. A lot of currently runtime values would have to turn into macros, 
such as `run-icon-color'. And I'd be writing an interpreter using syntax 
classes, a pale shadow of Racket.

Really, I'd rather cache things. I'm leaning toward not caching 
automatically, but providing users with `bitmap-file-ref!'.

Neil T