Future of "newRetinaText()" on iPad3?

Solar2D Daily Builds and Public Releases
#1

Hi Ansca,

This is both a question and a feature request: what can we expect from the recent “newRetinaText()” function with the pending release of the iPad3 in a few months? And with other super-sharp devices surely to follow? Will this API properly scale text up to the bleeding-high resolution of 1536x2048 on the iPad3? The documentation says that it provides a “double” resolution for current Retina devices, but the iPad3 will be the first " double-Retina" device on the market, 2x the iPad1&2 resolution and over 2x the iPhone4 (I’m excited about that!).

I suppose my “feature request”… and one that has been echoed by others… is for one solid, tested, reliable, and fast text API that works on all devices, current and future (I include “fast” in this request because I reported months ago about an instant 3-5 frame rate drop each time the “newText()” API is called). This ideal API would automatically display the text at the maximum pixel resolution for the device it’s running on, whether the screen width was 320 (iPhone3), 640 (iPhone4), or even 1536 (iPad3). It would also, obviously, need to accommodate proper reference point alignment like the original “newText()” function did.

In essence, I’m looking for some answers on the future of Corona text APIs. What can we expect going forth? Will these APIs be given priority attention? Because the usage of text is integral to basically any app (game, utility, business tool, etc.), it seems logical to focus on this in 2012… and with the iPad3 coming soon, developers will absolutely require “super-Retina” text on this device.

EDIT: Upon further testing, I think this issue needs “urgent” attention. I can see that the “newRetinaText()” function displays crisp, beautiful text on retina devices (iPhone4), but text on non-Retina devices (including iPad) is blurry. Tom (Ansca) responded in a thread that the iPad isn’t a Retina device (technically true), thus it doesn’t benefit from the “newRetinaText()” function. Because Corona somehow determines that the iPad isn’t “retina”, internally it calls the old “newText()” API instead, which produces blurry text. This simply shouldn’t be an issue at all… developers shouldn’t need to choose between text that looks great on Retina devices but blurry on other devices. I understand that the overall resolution of the iPad isn’t great (it’s basically a stretched-out iPhone4), but even considering this, the “newRetinaText()” function produces undesirably blurry text on iPad.

Sincerely,
Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 21012 reply_id: 321012[/import]

#2

Hi Brent,

I will bring this up in our next meeting and see what I can find out for you.

Peach :slight_smile: [import]uid: 52491 topic_id: 21012 reply_id: 83091[/import]

#3

I agree 100% with Brent here. I’ve taken up this issue in a few posts of my own, and this post reflects my opinion about the current text functionality in Corona.

The fuzziness is due to the scaling that takes place when developing apps using a smaller base canvas. With graphics we can use dynamic scaling and provide different versions for the resolutions we want to support. With text we’re stuck.
The issue goes away somewhat, even when using the current setText(), if you design the app for iPad by giving a base resolution of 768x1024 in config.lua, however that effectively deactivates Corona’s dynamic scaling (you can’t force Corona to use a *smaller* version of your graphics for devices that don’t require it).

It would be great if we could design our apps with any base resolution (like 320x480), and have Corona automatically adjust text so that it will always appear sharp and clear in the device’s native resolution by using one function only: newText().

EDIT:
At the moment I’m using my own newText function that should be future-proof even when the iPad3 comes around.

[lua]local newText = function(str, xPos, yPos, font, size)
local scaleY = display.contentScaleY;
local scaleFactor = 1.0 / scaleY;
local text = display.newText(str, 0, 0, font, size * scaleFactor);

text.xScale, text.yScale = scaleY, scaleY;
text:setReferencePoint(display.TopLeftReferencePoint) – Corona default
text.x, text.y = xPos, yPos;

return text;
end[/lua]
[import]uid: 70847 topic_id: 21012 reply_id: 83114[/import]

#4

@Peach
As always, thank you for listening and for being a liaison between us developers and the Ansca team. I’m curious to hear what you learn from Ansca on this. [import]uid: 9747 topic_id: 21012 reply_id: 83219[/import]

#5

@ingemar

Just to clarify, you can actually force Corona to use smaller images when you start with a large “base resolution” in your config.lua file. Instead of starting with something like 320x480 and then scaling up for higher resolution devices (i.e. 1.5, 2.0, 3.0 in your “imageSuffix” table), you can begin with a very high resolution like 1280x1920 and then invert your scaling DOWN as in 0.2, 0.5, 0.8. The effect on Corona’s internal image selection is identical… it still uses your defined ratios to select the proper image, only working high to low instead of low to high.

This also will, in fact, produce sharper text… I’ve tested this method on actual devices and I can confirm it. Because you’re starting with a higher resolution, all of your text sizes will be inherently greater… perhaps size 120 instead of 50. Then on “smaller” devices, that text *begins* at a higher value and is scaled down, which results in sharper text without using “retina” text or alternate functions.

Unfortunately, this method is only practical when you’re starting a new app, so you can design with the higher resolution from the start. If you’re 3/4 finished with an app, it’s alot of effort to reconfigure every image position in your code to a new screen position based on the higher resolution.

Anyway, this is just an aside mention. It doesn’t have much bearing on Corona’s current text API(s)… but it does show that you can configure your resolutions from high to low and achieve sharper text without any “workarounds”. However the improved text API that we both desire would hopefully make this method irrelevant.

Brent
[import]uid: 9747 topic_id: 21012 reply_id: 83263[/import]

#6

Actually, I was thinking about that approach, but I (wrongfully) assumed that it wouldn’t work since Corona’s dynamic scaling would need to choose smaller images instead of bigger ones, and I thought is was a “one way street”.
I’m going to make a test project and try this out…

Thanks for sharing.
[import]uid: 70847 topic_id: 21012 reply_id: 83318[/import]

#7

Brent is right, it is definitely possible to scale down instead of up, however, you put extra stress on the older devices’ already limited abilities. So depending on how memory and processor intensive your app is, and how far back you want to support devices (do you want to support the original iPhone or are you going for iPhone 4 and newer?) will determine how you should go about doing this.

However, I don’t see how the iPad 3 will need any different text functions than the iPhone 4 did. It’s just retina display on a bigger screen, nothing more. The fuzzy text on old devices is just because it’s on an old device that can’t usually handle the amount of texture memory that good resolution needs.

-Matt
W2MD [import]uid: 10211 topic_id: 21012 reply_id: 83622[/import]

#8

Matt brings up a good point, which I should have mentioned with my “scaling down” method. While this method yields the exact same results in suffix-based image selection, it can cause problems with text at very large sizes (yes, again with the text, yawn). If you set a text size of around “300” in the newText() API, it might not even appear on an iPhone3 or older! It just appears as a colored rectangle. I imagine this is because of the texture limitation sizes on those older devices.

Again, there currently isn’t a 100% viable solution for sharp text in Corona across all major devices. Hopefully somebody on the Ansca team with more technical know-how than myself can figure it out. :slight_smile:
[import]uid: 9747 topic_id: 21012 reply_id: 83651[/import]

#9

I really think a “Unified NewText” is something Ansca is working on (…right?)… maybe there are some issues that need to be solved before? A word or two from ansca could help.
I mean, I agree it’s just too weird to use two different functions to write text, especially since they exhibit also different behaviors and have different methods… something just not Corona-like.
[import]uid: 9158 topic_id: 21012 reply_id: 83652[/import]

#10

I’d recommend checking out the community Code Exchange for this one guys, I know several people have posted some solutions that attempt to work around Corona’s (kinda baffling) shortcomings in the text department.

I posted one a while ago: http://developer.anscamobile.com/code/dynamic-resolution-retina-text-class

It’ll scale to any resolution (including the proper widths and heights for multiline text) and unifies the text methods in general to make things easier to use. Just be sure to test on-device as it’s not 100% perfect.

But +1 to a revamped approach to text by Ansca! [import]uid: 87138 topic_id: 21012 reply_id: 84346[/import]

#11

Regarding retina text:

display.newText() has been modified to handle “retina text” automatically, and therefore display.newRetinaText() has been deprecated since it is no longer needed.

The changes will be reflected in the next daily build (the one posted *after* 2012.770).
[import]uid: 52430 topic_id: 21012 reply_id: 94932[/import]