Sub-pixel text rendering in Canvas revisited

[Jim Graham]

Is this issue what you are looking for?

http://javafx-jira.kenai.com/browse/RT-23822

			...jim

On 2/18/13 7:47 PM, John C. Turnbull wrote:
> 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
>>
>