As suggested by Robby and Eli here:
http://lists.racket-lang.org/users/archive/2013-March/056771.html
both `plot-frame' and `plot' (when `plot-new-window?' is #t) now create
frames in the caller's eventspace. Doing so fixes the problem talked
about in that thread, and seems like good behavior overall.
Plots created a separate eventspace because of the issue raised here:
http://lists.racket-lang.org/users/archive/2012-April/051485.html
in which a user was flummoxed by the fact that framed plots don't draw
during read loops in which events can't be processed, and the suggested
solution wasn't easy or obvious. Users may get Plot's old behavior by
(parameterize ([current-eventspace (make-eventspace)])
(plot ...))
which, though still not obvious, is at least easy.
Related to PR 13535: from the user's feedback, plots having their own
eventspaces may cause framed plots to render at the wrong size
initially, and may partly cause them to not redraw when their frame
is resized. Hopefully the eventspace change fixes one or both
problems.
If not, maybe this will: 2d-plot-snip% and 3d-plot-snip%, which
descend from image-snip%, now properly call the superclass method
within their `resize' overrides, so their editors will be notified
of the change and hopefully redraw them.
At mbutterick's recommendation:
it's causing a strange display problem in TOC listings when the
cursor is hovering over the link (namely, the underlined space
dangling from the right edge)
The bug particularly broke `#:async-apply` handling for an FFI callback,
causing the current thread always to be equated with the target thread.
For example, the teachpack documentation (which now renders images
to SVG) kept crashing on a multi-place build due to callbacks getting
invoked in the wrong place.
It's not clear that there's actually any path from the adjusted calls
to the PDF/SVG bytes-writing callback, but in principle, arguments
to Cairo and Pango calls must not be moved by the GC.
Before, they would create a crippled version in that mode, but
that is no longer necessary (it may never have been necessary,
but it certainly hasn't been necessary in a while)
