Sub-pixel text rendering in Canvas revisited

[Jim Graham]

Phil's comment about the API was not about bloat, it was about designing 
an API before we understood the issues and how developers were facing 
them.  We fully understood the issues that would affect LCD rendering of 
a Text Node and so that has API to control it, but we do not yet 
understand all of the issues that would affect LCD text for Canvas (and 
some of what I said before that we think we might understand turns out 
is not necessarily completely accurate in the face of Windows 8 HiDPI 
scaling so perhaps it is a good thing that we waited).

I explained the technical issues on another message on this mailing 
list.  I'll include that description here:

> One issue with canvas is that LCD text needs to be rendered when the
>  device space transform is known.  With Canvas we know what the pixel
>  space is of the backing raster, but the transform that is applied
>  when we render the backing raster to the screen (which is probably
>  identity in many common cases) can wreak havoc with the sub-pixel
>  work we did on the text.  If we provided a control for it on
>  GraphicsContext then you'd have to commit to not involving the
>  canvas in any transforms except for integer translations.
>
> Also, I'd have to think about how this would be affected by HiDPI
>  as well.  The typical Apple retina screen would be a simple 2x
>  scale so the same integer translate restriction would still work
>  fine, but I haven't delved too deep into what scaling options
>  Windows 8 offers...
>
>             ...jim

Note that comparing our LCD text capabilities to Flash and Silverlight 
would better use our Text node as a comparison.  If I understand 
correctly, Flash and Silverlight rerender the text for every frame of an 
animation and so they can adjust it for the specific final transform and 
pixel layout of the screen they are animating on.  Canvas is an image 
you can render into and then move/scale/stretch/rotate that image 
afterwards so to do LCD text on that would be better compared to whether 
Photoshop can implement LCD text in an image you save.  Also, I was 
under the impression that HTML5 Canvas did not do LCD text (yet).  At 
least I see no API related to it in the latest cuts of the API that I've 
looked at and when I search for it I see people asking why their HTML5 
Canvas text is grayscale when their browser text is LCD (usually for the 
same reason - HTML5 is implemented as a pixel store, not a list of 
graphics commands to be reiterated during animations).

Also, we now have an idea of what is involved with HiDPI on Mac Retina 
and Windows 8 and it doesn't look promising.  If we rasterize at 2x for 
a Mac Retina display and the window is dragged to a non-Retina display 
than our attempts to do LCD at 2x will look worse than if we had done 
grayscale - though LCD text on a Retina display is already overkill. 
Windows 8 documents indicate that applications should prepare to render 
with 1.4 and 1.8 pixel scaling so they do not have an even multiple so 
my caveats above about how Mac Retina's 2x pixel scaling would not 
affect LCD restrictions on Canvas are unfortunately not applicable to 
HiDPI Windows 8 screens.  :(

This requires more testing and analysis before we can offer an LCD text 
API on GraphicsContext that doesn't create more problems than it solves...

		...jim

On 2/18/13 2:09 AM, John C. Turnbull wrote:
> Some time ago I posted about my wish for Canvas to support sub-pixel
> antialiased text rendering (also known as LCD text rendering).
>
>
>
> At the time, some resistance to the idea was expressed (from the JavaFX
> development team) on the basis that adding a method to set the text
> "smoothing" type in Canvas would result in API bloat.  In addition, some
> comments were made in relation to the difficulty of rendering LCD text with
> transitions and animations.
>
>
>
> I would like to restate that I strongly believe that Canvas needs to support
> LCD text.  I simply cannot see that adding *one* method to an API is
> equivalent to "bloat". Also, while I profess that I am no advanced graphics
> expert, I am not sure why LCD text would cause unsolvable problems for
> transitions/animations given that other graphics toolkits (i.e. Flash,
> Silverlight and even HTML5 Canvas) are all capable of rendering LCD text and
> having such text participate in animations.  What makes JavaFX so different?
>
>
>
> So, is it possible the decision not to support LCD text in JavaFX Canvas be
> reconsidered?  As I said in my original post, the main driver for me is that
> I would like to develop advanced controls based on Canvas but am concerned
> that the text in said controls looks distinctly different (i.e. much
> poorer/fizzier) than text rendered in "standard" controls (i.e. those not
> based on Canvas).  The result is a non-uniform and substandard UI.
>
>
>
> Thanks,
>
>
>
> -jct
>