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)
In an ultimately vain attempt to make plotting fast but still allow
plots with bounds that have very few flonums in them, Plot used to try
to detect when each axis's bounds had enough flonums in it and switch to
flonum-only math. There are two problems with this:
* It was trying to determine whether *future computations* would have
enough precision, which is very difficult to know for sure, so it
only *usually* worked. (Example fail: contour-intervals3d with 0 and
+max.0 endpoints. Half the isobands weren't drawn.)
* It caused extra conversions between flonums and exact rationals,
which are very slow.
Here's the new approach:
1. Always send exact rationals to user functions (e.g. the lambda
arguments to `function' and `contour-intervals3d').
2. Immediately convert user-given plot coordinates to exact
rationals (if rational; e.g. not +nan.0)
3. Always represent normalized coordinates (e.g. in [0,1]^2 for 2D
plots and [-1/2,1/2]^3 for 3D plots) using flonums.
4. Reduce the number of exact operations as much as possible.
IOW, plot coordinates, which can be incredibly huge or tiny and don't
always fit in flonums, are always exact internally. Normalized, view,
and device coordinates, which are used only internally, always have
bounds with plenty of flonums in them, so Plot uses flonums.
Doing #4 accounts for most of the changes; e.g. to the marching
squares and marching cubes implementations, and axial plane clipping.
Most plots' speeds seem to be unaffected by the changes. Surfaces and
contour intervals are sometimes faster. Isosurfaces are a tad slower
in some cases and faster in others. Points are about 50% slower,
partly undoing the speedup from a recent commit. Plots with axis
transforms can be much slower (4x), when long, straight lines are
subdivided many times. Plots with bounds outside flonum range seem
to be about 3x faster.
The `(letrec ([x x]) x)` pattern for getting the undefined value will
cease to work in a near-future version of Racket (ater
v6.0.1). Instead, the initial refernce to `x` will produce a "variable
used before its definition" error.
For libraries that need an "undefined" value, this new library
provides `undefined`, and the library will continue to work in future
Racket versions.
The library also provides a `check-no-undefined` operation that
normally should be wrapped around an expression to keep it from
producing `undefined`. For example, the class system initializes
object fields with `undefined`, but it could (and will, eventually)
wrap each access to a field within `class` to check that the field's
value is not `undefined`.
This makes plotting to a file the same (well, with slight differences)
regardless of file format. Scaling and other PS options are controlled
by a `plot-ps-setup' parameter. Not sure how useful that is, yet, so
it's undocumented.
The old depth sort hack split up groups of identical points in order
to sort them. Now the BSP tree build keeps them grouped, only splitting
groups of points as needed. Drawing parameters like color and pen
width are set only once for each group instead of once for each point.
The speedup is from reducing the number of calls to set them.
Previously, the BSP type had a "negative" and "positive" subtree, and
a collection of unsorted "zero" (on the plane) shapes. Rather than "zero"
being a subtree (which would sort the shapes), it's rolled into "positive",
with corresponding changes to the BSP walk.
BSP tree build now supports scenes without polygons, though it does split
on polygonal planes first. When all such splits fail (usually because there
are no polygons, but might be because all the shapes lie on one polygon's
plane), it tries splitting on planes containing line segments. When that
fails (usually because there are no line segments), it tries splitting
disjointly on all remaining vertexes, then splitting at the midpoint of
the longest axis.
Upshot: it'll draw a double helix created by two `parametric3d' renderers
properly.
The new method finds bounding planes for polygons using their
(approximate) normals and works for any number of them instead of
just two. The algorithm is O(n^2) where n is the number of polygons,
so it is currently applied only when n <= 5; i.e. near the leaves.
