Inconsistent Rendering of newLine objects...

Solar2D Advanced Graphics
#1

I use vector graphics extensively to create Cartesian graphs and grids that are dynamically configurable, zoomable, moveable etc.

I have been using these techniques for quite some time on many platforms.  I am getting really inconsistent rendering of the display.newLine() object.

I’m posting this as a topic to find out if anyone else is experiencing the same thing and if there area workarounds, settings, etc. to correct the problem.

The following function works perfectly in an isolated test case.  The graphics look clean and crisp on each form factor.

function scene:create( event ) local sceneGroup = self.view local i = 1 local box = display.newRect(sceneGroup, display.contentCenterX, display.contentCenterY, 500, 500) box.fill = {.2, .2, .2} local grid = {} for i = 1, 10, 1 do grid[i] = display.newLine( sceneGroup, i \* 20, 0, i \* 20, display.contentHeight ) grid[i].stroke = {.8,.2,.2} grid[i].strokeWidth = 1 end end

When I apply the same technique in my app, I get inconsistently rendered lines (different pixels wide or missing).  

Wondering if I’m missing something before I post a bug report.

#2

Saw another post about scaling.  Tried the fix below.  Still not working.

local lineWidth = function (width) local width = width width = math.ceil(width / display.contentScaleY) \* display.contentScaleY return width end
#3

for axis-oriented cartesian, i prefer to just stretch pre-rendered line bitmaps

assume they’re laid out horizontally (say, in a 64x8 bitmap, filling completely end-to-end, leaving some vertical pixels for antialiasing), you can set xScale as wide as you like with no distortion, and rotate 90 for your verticals.

you can alter yScale *a little* for thicker/thinner lines, but beyond a little bit your antialiased edges will start to “feather out”, and you should switch to another bitmap closer in actual stroke width.  (if you know all your stroke widths in advance, then just precreate exactly that many bitmaps of those specific widths)

(there are also bitmap stroke tricks you can use, similar in result)

#4

Hmm.  So CSDK folks use bitmaps and not the built in vector graphics?  I tend to use bitmaps sparingly because I can’t scale them easily.  However, it looks as if vectors don’t scale very well in CSDK either.

Thinking…

I suppose I could create an array of different sized bitmaps and select the one that works best based upon the size I want.  There would be constraints on the amount of scaling I could do, but that would work ok for devices since the screen real estate is basically known.

How well does this work across form factors (IOS types, Android types, etc)?

#5

So what is the best way to handle coloring the bitmaps?  Do I need to also create an array of colors?

#6

vectors do scale well, but when rendered get pixelized without antialiasing, so you get truncation errors in line widths and positional “shimmering” if on non-integral coordinates, and other such non-pleasant artifacts.  Bitmaps can work around almost all of those problems just because they’re rendered differently.

About the only time you can get absolutely reliable vector results is if you’re runing at 1:1 display resolution (fe, config.lua would have width=display.pixelWidth, height=display.pixelHeight), and YOU are doing any necessary scaling yourself.  Then you’ll have access to native pixels, so you can draw “perfect” horizontal/vertical lines on those exact pixels.  Otherwise, bitmaps…

if you choose this route…

create them pure white (and transparent of course)

fill color on a bitmap then acts as “tint” as you’d expect

[edit:  and as said earlier, the other option with similar results is to stay vector but use a bitmap stroke, in either case the filtering that occurs during texture sampling of the bitmap will approximate the antialiasing you’re after)

hth

#7

@davebolligner

Hah.  Won’t quibble about what “scaling well” means. :slight_smile:  Basically CSDK renders bitmaps much better than raw vector rendering.

It seems like using a bitmap for the stroke is the most logical way forward for me since I have a lot of vector dependent algorithms.  Is there a good tutorial, or do you have insights about what works best.  8x8 square or something like 8x64?

Thanks for your help on this.

–Scot

#8

for “bitmaps as strokes on vector lines”:

since your avatar says pro license, you should probably start here and use the features you paid for! :smiley:

http://coronalabs.com/blog/2013/10/24/tutorial-fills-and-strokes-in-graphics-2-0/

(you can use a bitmap as a stroke as well as fill, not sure that tutorial fully covers that aspect but it’s a logical extension of what’s there)

or, for “bitmaps as the lines themselves”, i just blogged this with functional code:

http://davebollinger.org/corona-quick-thought-cheap-antialiased-lines/

hth

#9

Hey Dave,

Used a 1x8 bitmap as a stroke fill.  I made the image using transparency for antialiasing and a strokeWidth of 4.  Worked out very nicely.  Thanks for your help.

Thanks,

–Scot

#10

It is the same problem related to my post here: http://forums.coronalabs.com/topic/49885-why-these-stroke-problems-happen/

Glad that you solved.

#11

Saw another post about scaling.  Tried the fix below.  Still not working.

local lineWidth = function (width) local width = width width = math.ceil(width / display.contentScaleY) \* display.contentScaleY return width end
#12

for axis-oriented cartesian, i prefer to just stretch pre-rendered line bitmaps

assume they’re laid out horizontally (say, in a 64x8 bitmap, filling completely end-to-end, leaving some vertical pixels for antialiasing), you can set xScale as wide as you like with no distortion, and rotate 90 for your verticals.

you can alter yScale *a little* for thicker/thinner lines, but beyond a little bit your antialiased edges will start to “feather out”, and you should switch to another bitmap closer in actual stroke width.  (if you know all your stroke widths in advance, then just precreate exactly that many bitmaps of those specific widths)

(there are also bitmap stroke tricks you can use, similar in result)

#13

Hmm.  So CSDK folks use bitmaps and not the built in vector graphics?  I tend to use bitmaps sparingly because I can’t scale them easily.  However, it looks as if vectors don’t scale very well in CSDK either.

Thinking…

I suppose I could create an array of different sized bitmaps and select the one that works best based upon the size I want.  There would be constraints on the amount of scaling I could do, but that would work ok for devices since the screen real estate is basically known.

How well does this work across form factors (IOS types, Android types, etc)?

#14

So what is the best way to handle coloring the bitmaps?  Do I need to also create an array of colors?

#15

vectors do scale well, but when rendered get pixelized without antialiasing, so you get truncation errors in line widths and positional “shimmering” if on non-integral coordinates, and other such non-pleasant artifacts.  Bitmaps can work around almost all of those problems just because they’re rendered differently.

About the only time you can get absolutely reliable vector results is if you’re runing at 1:1 display resolution (fe, config.lua would have width=display.pixelWidth, height=display.pixelHeight), and YOU are doing any necessary scaling yourself.  Then you’ll have access to native pixels, so you can draw “perfect” horizontal/vertical lines on those exact pixels.  Otherwise, bitmaps…

if you choose this route…

create them pure white (and transparent of course)

fill color on a bitmap then acts as “tint” as you’d expect

[edit:  and as said earlier, the other option with similar results is to stay vector but use a bitmap stroke, in either case the filtering that occurs during texture sampling of the bitmap will approximate the antialiasing you’re after)

hth

#16

@davebolligner

Hah.  Won’t quibble about what “scaling well” means. :slight_smile:  Basically CSDK renders bitmaps much better than raw vector rendering.

It seems like using a bitmap for the stroke is the most logical way forward for me since I have a lot of vector dependent algorithms.  Is there a good tutorial, or do you have insights about what works best.  8x8 square or something like 8x64?

Thanks for your help on this.

–Scot

#17

for “bitmaps as strokes on vector lines”:

since your avatar says pro license, you should probably start here and use the features you paid for! :smiley:

http://coronalabs.com/blog/2013/10/24/tutorial-fills-and-strokes-in-graphics-2-0/

(you can use a bitmap as a stroke as well as fill, not sure that tutorial fully covers that aspect but it’s a logical extension of what’s there)

or, for “bitmaps as the lines themselves”, i just blogged this with functional code:

http://davebollinger.org/corona-quick-thought-cheap-antialiased-lines/

hth

#18

Hey Dave,

Used a 1x8 bitmap as a stroke fill.  I made the image using transparency for antialiasing and a strokeWidth of 4.  Worked out very nicely.  Thanks for your help.

Thanks,

–Scot

#19

It is the same problem related to my post here: http://forums.coronalabs.com/topic/49885-why-these-stroke-problems-happen/

Glad that you solved.