[racket-dev] [plt] Push #28009: master branch updated

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, mflatt at racket-lang.org wrote:
>>>> bd4d0b7 Matthew Flatt <mflatt at 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