Sub-pixel text rendering in Canvas revisited

[John C. Turnbull]

Yes, thanks Jim.  I will vote for it!

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

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
>>
>