Sub-pixel text rendering in Canvas revisited

[John C. Turnbull]

Thanks Jim for a very comprehensive reply.

>From what you have outlined, there certainly seem to be many issues, most of
which I was not aware of and many that I do not fully understand.  I guess
it's a brave new world now with various pixel densities and OSes at play.

However, I still see it as vital that LCD text be supported in Canvas.  Of
course I am not advocating a "half-baked" approach where we haven't
considered all the factors but I do think that it's something that should be
put on the official roadmap (at least putting a deeper investigation on the
roadmap).

Perhaps this is already the case? Should I file a feature request in JIRA or
does one already exist?

Thanks,

-jct

-----Original Message-----
From: Jim Graham [mailto:james.graham at oracle.com] 
Sent: Monday, 18 February 2013 21:41
To: John C. Turnbull
Cc: openjfx-dev at openjdk.java.net
Subject: Re: Sub-pixel text rendering in Canvas revisited

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
>