First, you can’t draw a line thinner than one content unit or point To give the illusion of thinner line, you use a lighter color.
Secondly, because screens come in different sizes, it’s almost impossible to have a Corona content area that is pixel perfect. Depending on where the line is drawn you might get a different pixel width because pixels ~= points.
source of the problem: lines will be rendered with weights in content units, then scaled to device units as needed, and potentially displayed at non-integral device coordinates. so you can wind up with a 0.75 device pixel line width, displayed at y=10.3, both of which will cause aliasing and a potential misrepresentation of the apparent line width.
there are a couple things you can do to improve (but not entirely correct) the results
render your own dividers, instead of letting tableview do it (use noLines option), but create them as rects instead of lines (because rect dimensions are easier to control than line widths)
decide if you’d rather size your rect (aka adjust its “stroke width”) based on content units or device units. fe:
– line is two content units tall: lineThickness = 2 – OR – line is two device units tall: lineThickness = 2 * display.contentScaleY – then… rect = display.newRect(row.width/2, row.height-lineThickness/2, row.width, lineThickness)
you’ll still get antialising at non-integral scroll positions, can’t help that, but if you size the thickness correctly with rects, it should be less noticeable than line stroke weights.
First, you can’t draw a line thinner than one content unit or point To give the illusion of thinner line, you use a lighter color.
Secondly, because screens come in different sizes, it’s almost impossible to have a Corona content area that is pixel perfect. Depending on where the line is drawn you might get a different pixel width because pixels ~= points.
source of the problem: lines will be rendered with weights in content units, then scaled to device units as needed, and potentially displayed at non-integral device coordinates. so you can wind up with a 0.75 device pixel line width, displayed at y=10.3, both of which will cause aliasing and a potential misrepresentation of the apparent line width.
there are a couple things you can do to improve (but not entirely correct) the results
render your own dividers, instead of letting tableview do it (use noLines option), but create them as rects instead of lines (because rect dimensions are easier to control than line widths)
decide if you’d rather size your rect (aka adjust its “stroke width”) based on content units or device units. fe:
– line is two content units tall: lineThickness = 2 – OR – line is two device units tall: lineThickness = 2 * display.contentScaleY – then… rect = display.newRect(row.width/2, row.height-lineThickness/2, row.width, lineThickness)
you’ll still get antialising at non-integral scroll positions, can’t help that, but if you size the thickness correctly with rects, it should be less noticeable than line stroke weights.