Sub-pixel text rendering in Canvas revisited
John C. Turnbull
ozemale at ozemail.com.au
Thu Feb 21 13:30:17 PST 2013
Yes, thanks Jim. I will vote for it!
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?
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?
> -----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
> 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...
> 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
> 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.
More information about the openjfx-dev