Hi,
I’m using TableView for the first time and I’m having trouble with the line that appears between rows. I can see how to set the colour of it, but I can’t see how to set the width?
The problem I have is that it’s not going all the way across the TableView - it’s sitting approx 8 pixels in from the left and about 2 pixels in from the right.
Is this by design?
Thanks,
Nathan.
Hi Nathan,
Yes, this is by design. I actually prefer (and recommened) keeping the “noLines” parameter as “true” and then rendering your own lines (or thin vector rectangles) as part of each row. This will give you more control over the color, style, and width.
Brent
OK thanks Brent.
Hi Nathan,
Yes, this is by design. I actually prefer (and recommened) keeping the “noLines” parameter as “true” and then rendering your own lines (or thin vector rectangles) as part of each row. This will give you more control over the color, style, and width.
Brent
OK thanks Brent.
So we went for creating our own lines, but now it seems to “jitter” when scrolling - it’s like creating the line object in the renderRow function is a problem (given that renderRow is being called all the time when scrolling is occurring).
The line seems to flick between 1 pixel wide, to 2 pixels, to 0 pixels - resulting in a glitchy looking scroll.
Is this is known issue, or something about they way I have it configured?
The row rendering function should be called just once per row when we believe the row needs to be created. It does not get called for existing rows as they scroll. Are you seeing this on device or in the simulator? If it’s the simulator only, what zoom level are you at? This sounds a lot like having to downsample the screen to have it fit. For instance if you’re simulator is at 50% zoom level and you draw a 2px line, it’s only going to render as one and since we work in content unit points and not pixels, what you might see as a 2 point line on a 800x1200 content area be a 1.5 point line on a 640x960 device. (approx math).
The inherent “rounding” of thin lines compared to actual content area pixels is my suspicion as well.
Brent
Ahh - thanks guys. Had a deeper look and you are right - it’s not re-rendering rows when they are on-screen.
It’s happening in the simulator and on all devices. Even when the sim is at 100% we’re still seeing the issue.
Our config.lua is…
width = 320,
height = 480,
scale = “letterbox”
Could this be part of the problem? Could it be trying to scale dimensions live and ending up with cases where a line is sometimes 2 pixels and other times when it’s 1?
What would you recommend to avoid this? Esp when we’re deploying to lots of different shaped devices.
Thx,
Nathan.
This can happen when Corona is using a fractional content scale. Odds are you are setting the line width to 2 in content coordinates, but when converted to pixels, it becomes a fractional width. Since there is not such as a fractional pixel onscreen, the GPU is forced to interpolate the line the best it can across the pixels on the screen. So, as you scroll the TableView, you’ll see the line widths increase/decrease in size by 1 pixel as it scrolls.
To avoid this, you need to set the line width in pixels and not in Corona’s content coordinates. You can do so as follows…
-- The line width you want in content coordinates. local lineWidth = 2 -- Round up the line width to the nearest whole number pixel. lineWidth = math.ceil(lineWidth / display.contentScaleY) \* display.contentScaleY
One more thing to note. The above fixes this issue on all mobile device screens, but this issue will still happen in the Corona Simulator if not using a 100% zoom level. So, set the zoom level to 100% to confirm the above fixes the issue.
I hope this helps!
Thanks Joshua - that was the fix we needed!
Regards,
Nathan.
Actually… testing on a wider variety of devices and we’re still having problems.
Worked well in the sim where contentScaleY = 0.5, but on the iPhone 6S contentScaleY is 0.42666667699814 which results in a linewidth of 1.28000003099442 it is exactly as before - flipping from 1 pixel to 2 pixels wide every time you scroll.
Testing on a decent Android device shows contentScaleY of 0.29629629850388 and it’s smooth as silk.
I also tried it on our iPad PRO and it’s the same as the 6S - still very jittery.
Hmm… well our math is definitely right. The formula I gave you will work on all Android devices of various resolutions. It’ll work for desktop apps (Mac and Win32) as well.
I’m not an iOS developer, but I find it interesting that this issue only happens to you on an iPhone 6S and iPad Pro, both of which do not have even scale factors from a base resolution of 320x480 for iPhones and 1024x768 for iPads. For example, an iPhone 5S has a 640 pixel width which is exactly 2x wider than the old 320 pixel wide iPhone. But an iPhone 6S is 750 pixels wide, which is the first Apple phone to not have an even scale factor.
I’m wondering if your app is being put into backward compatibility mode on the iPhone 6S, forcing iOS to scale up your app. What does the following APIs return for you on the iPhone 6S and iPad Pro for you?
display.pixelWidth
display.pixelHeight
Just to add to my last post, your app will be put into backward compatibility mode on an iPhone 6S, 6+, and iPad Pro if your app is missing the following PNG files in your project’s root directory:
What will happen is that iOS will make your app think it’s running on a lower resolution device than it really is and then scale-up your app by a fractional amount. Native apps (not just Corona built apps) will be unaware that this is happening. If iOS is scaling up your app, then that would account for the line widths shifting size as you scroll as well because the math I posted above will be unable to correct round-up to the next whole pixel, because, well, iOS is lying to us about the actual pixel resolution. To resolve this issue and run your app at the devices true pixel resolution, you’ll have to add the above files. Have a look at the following documentation (link below) for more details. There are other default launcher images that you might want to ensure your project has.
https://docs.coronalabs.com/daily/guide/distribution/buildSettings/index.html#launch-images
And I recommend that you set these launch images to pure black. That’s a simple way to handle them and allows iOS to do a nice fade from black to your app’s start screen on startup.
Anyways, I hope this helps!
Looks like we weren’t carrying the 736 splash screen or the 1366 - included both, but it didn’t make a difference. I think 736 is for 6+ anyway? 667 seems to be the one associated with the 6 and 6S.
Note we only allow portrait, so I don’t even include the landscape versions.
6S is showing:
contentScaleY = 0.42666667699814
pixelWidth = 750
pixelHeight = 1334
Can you tell me what your content width and height are set to in your “config.lua” file please?
While I can calculate it for myself, I get what’s shown below…
-- This is the formula. scaleY = contentHeight / pixelHeight contentHeight = scaleY \* pixelHeight -- Me attempting to calculate your content height. contentHeight = 0.42666667699814 \* 1334 = 569.17334711551876
The above result doesn’t look right. I highly doubt you are setting your content height to 569.17334711551876.
width = 320,
height = 480,
scale = “letterbox”
Any ideas? I’m really confused by this - frustrating that it’s fixed on Android, but still a problem on iOS.
When I last heard the status on this, the team was trying to find a 6S to test on. But it’s now the holiday weekend, so we will probably dig into this more tomorrow or over the next few days.
Rob
It’s not a 6S specific problem - it’s all iOS devices, and the Corona simulator (at 100%).