That sounds right, and your description of the difference perfectly
explains why the plots were wrong. Polygon vertexes were snapped to the
nearest *drawing context* unit instead of the nearest *destination*
unit. IOW, they were aligned with a low-resolution grid. Of course they
were lumpy.
I agree that the default alignment scale should be 1. If a function
receives a bitmap from somewhere that may have backing scale != 1,
drawing operations should still work as expected, except the resolution
of the result may be higher or lower.
The plots look great with your recent changes, and I look forward to
unbreaking them after you break them again. :)
How does DrRacket look on Retina displays now? Can you post part of a
screenshot?
Neil ⊥
On 01/05/2014 01:47 PM, Matthew Flatt wrote:
After further exploration, I think I'm going to have to re-break your
program and give you a way to un-break it.
The issue is what "aligned" means:
* "Pixel-aligned" makes drawing to a bitmap with a backing scale of 2
(at scale 1) consistent with drawing at scale 2 to a bitmap with a
backing scale --- as you wanted.
* "Unit-aligned" makes drawing to a bitmap with a backing scale of 2
more consistent with drawing to a bitmap with backing scale 1.
The change I pushed was essentially from "unit-aligned" to
"pixel-aligned", because "pixel-aligned" seems to better match the goal
of aligned drawing.
But "pixel-aligned" changes the meaning of alignment in a way that
breaks programs. For example, the caret in an editor becomes slightly
mangled on boundaries: it's normally drawn with a pen width of 1 in
unsmoothed/aligned mode at integer unit positions, which makes the
drawing shift left by one Retina pixel in Retina mode.
I think the solution is to allow a backing scale and an alignment scale
to be different in a drawing context. (More precisely, the backing
scale is a property of a drawing destination, while alignment scale is
a property of a drawing context.) By default, I think a DC's alignment
scale should be 1 (i.e., unit-aligned) for compatibility. For your
purposes, then, you'll need to explicitly set the DC's alignment scale
to 2 to match the backing scale.
Does that sound right/ok?
At Sun, 5 Jan 2014 08:55:12 -0700, Matthew Flatt wrote:
Thanks --- I think I've fixed alignment for drawing to a bitmap with a
backing scale.
At Fri, 03 Jan 2014 19:33:22 -0700, Neil Toronto wrote:
On 01/03/2014 06:12 PM, mfl...@racket-lang.org wrote:
bd4d0b7 Matthew Flatt <mfl...@racket-lang.org> 2014-01-03 17:57
:
| if a bitmap has a non-1 backing scale, always draw smoothly to other
contexts
:
M pkgs/draw-pkgs/draw-lib/racket/draw/private/dc.rkt | 11 ++++++-----
Cool. It looks like this solved another issue as well: drawing 2x
bitmaps in the REPL would smooth only intermittently.
There appears to be a problem with drawing in 'unsmoothed mode onto a
bitmap with a backing scale. I've attached a program that demonstrates
using a single polygon and with plots.
In the single polygon test, the triangle drawn onto the 2x bitmap is
shifted down and to the right one pixel.
The code that draws a plot onto a 2x bitmap simulates the change I would
make to Plot to take advantage of the new backing scale feature. The
edge of the sphere looks lumpy, probably because polygons are drawn
unsmoothed and their vertices are being snapped to the wrong places. The
second plot shows how it's supposed to look.
The last two plots show how each looks before being scaled down. The
lumpiness around the edge is probably easier to see this way.
Neil ⊥
------------------------------------------------------------------------------
[text/plain "unsmoothed-polygons.rkt"] [~/Desktop & open] [~/Temp & open]
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
