Display elements disappear when stroke width is set to 1

Solar2D Win32 Desktop
#1

I’ve been working with Corona SDK for a few months building a Win32 business app, and am now trying to refine some of the graphics. 

In one particular scene, I’ve used multiple rectangles for framing different areas of the screen. While experimenting with different rectangle dimensions and stroke widths I noticed that entire rectangles will occasionally disappear when I set the total width to 1. Other rectangles lose a single side, but retain the rest of their outline when the strokeWidth is set to 1. At first I thought this must have been due to overlapping display elements, such as text fields, that were wider than I realised. But after much experimentation - introducing large offsets between neighbouring elements and trialing a variety of width and stroke dimensions - the only way to make the rectangles/sides reappear was increasing the width/strokeWidth values.

The behaviour is confusingly inconsistent between rectangles. Some elements are affected, some are not, and all my rectangles have neighbouring elements.

Is this a super simple rookie error? Is there something apart from overlapping neighbouring elements that I should check?

Any advice would be much appreciated!

#2

I recently stumbled across this discussion:

https://forums.coronalabs.com/topic/49885-why-these-stroke-problems-happen/

Which makes me think that the problems I’m experiencing could come down to OpenGL struggling to decide how many pixels should be used for the shapes/lines that I’m drawing.

Since reading the post, I’ve been on the look out for other disappearing lines in my built Win32 app and noticed that the horizontal lines in my listviews are also pretty temperamental. Most of them are fine, but whenever I stop scrolling there are often one or two expected lines that aren’t rendered.

Any wise Corona sage out there able to weigh in on this? If the explanation in the link does tie to this problem too, the question would then be how to apply the kind of correction described in the above link to elements other than individual lines.

#3

What are your config.lua settings?

If you have a very high resolution set here, and the device resolution is lower, 1 pixel (or rather, unit) may be rounded down to 0 pixels when the scaling is applied.

#4

Cheers for the response Nick. Here’s my config.lua:

application = { content = { width = 768, height = 1366, scale = "letterbox", fps = 60, }, }

I’m guessing this resolution is up the higher end of things? That said, the 22" monitors I’m using seem to be running 1920x1080, which I would have thought is higher again. In choosing values for the config.lua file I was trying to target what I read was the most common desktop screen type.

#5

Are you displaying the simulator on the whole screen or just a portion of it?

#6

Just a portion of the screen - I can see the entire simulator window as well as other applications that I have open on my monitor.

Important to note - the problems I’m describing aren’t confined to the simulator - the behaviour remains when I build the app for Windows as well and run the executable.

#7

Well that explain the simulator issue, unless it is taking up at least 1366 x 768 of the screen, one unit is equal to less than one pixel. 

What resolution is your desktop app setup to display by default? This isn’t necessarily the same as what’s in config.lua.

#8

Right. That makes sense.

No idea what the default resolution is - if it’s not defined by config.lua, where is it defined? Whenever I’ve changed the height and width values in config.lua in the past this has seemed to alter the default dimensions of the app window when I run the executable (i.e. increasing these values results in a larger window on opening).

Resizing the app window solves the temperamental behaviour of the listview lines. They’re pretty stable (in that none of them disappear while on-screen) however their widths still seem to fluctuate a bit.

Zooming in on the simulator does cause the vanishing lines to reappear - increasing the size of the app window does the same for the built app as well - thanks, Nick!

That’s most of my initial queries answered, however even when I’ve resized the app window to fill as much of my monitor as possible I’ve noticed that the corners of my rounded rectangles are still rough and pixelated. All my PNG files seem to be rendering fine and text looks alright as well. Any insight into the ugly rectangles?

Also, what’s the best-practise approach to building versatile apps that don’t have elements disappear when displayed on larger screens? Simply go for a lower resolution? Or is it possible to apply the mathematical rounding approach proposed in the link I posted to elements like listviews and rectangles?

Sorry for the barrage of questions. Cheers for the help.

#9

These are Corona’s rounded rects? Unfortunately the built-in shapes are of poor quality that are only fit for 480x320, you might have to roll your own rounded rects to get a quality result on desktop. Or perhaps RoamingGamer’s SSK2 has something like that built in?

#10

Desktop resolution options are defined in build settings, there’s some docs on here somewhere.

I think I just always used a strokeWidth of at least 2 to get round this issue.

#11

Yep, rounded rects from Corona. Shame about that, but good to know. Will have to check out RG’s kit.

Champion, Nick. Thanks for the advice. I ended up switching most of my lines to 2 already. I appreciate the help!

#12

I recently stumbled across this discussion:

https://forums.coronalabs.com/topic/49885-why-these-stroke-problems-happen/

Which makes me think that the problems I’m experiencing could come down to OpenGL struggling to decide how many pixels should be used for the shapes/lines that I’m drawing.

Since reading the post, I’ve been on the look out for other disappearing lines in my built Win32 app and noticed that the horizontal lines in my listviews are also pretty temperamental. Most of them are fine, but whenever I stop scrolling there are often one or two expected lines that aren’t rendered.

Any wise Corona sage out there able to weigh in on this? If the explanation in the link does tie to this problem too, the question would then be how to apply the kind of correction described in the above link to elements other than individual lines.

#13

What are your config.lua settings?

If you have a very high resolution set here, and the device resolution is lower, 1 pixel (or rather, unit) may be rounded down to 0 pixels when the scaling is applied.

#14

Cheers for the response Nick. Here’s my config.lua:

application = { content = { width = 768, height = 1366, scale = "letterbox", fps = 60, }, }

I’m guessing this resolution is up the higher end of things? That said, the 22" monitors I’m using seem to be running 1920x1080, which I would have thought is higher again. In choosing values for the config.lua file I was trying to target what I read was the most common desktop screen type.

#15

Are you displaying the simulator on the whole screen or just a portion of it?

#16

Just a portion of the screen - I can see the entire simulator window as well as other applications that I have open on my monitor.

Important to note - the problems I’m describing aren’t confined to the simulator - the behaviour remains when I build the app for Windows as well and run the executable.

#17

Well that explain the simulator issue, unless it is taking up at least 1366 x 768 of the screen, one unit is equal to less than one pixel. 

What resolution is your desktop app setup to display by default? This isn’t necessarily the same as what’s in config.lua.

#18

Right. That makes sense.

No idea what the default resolution is - if it’s not defined by config.lua, where is it defined? Whenever I’ve changed the height and width values in config.lua in the past this has seemed to alter the default dimensions of the app window when I run the executable (i.e. increasing these values results in a larger window on opening).

Resizing the app window solves the temperamental behaviour of the listview lines. They’re pretty stable (in that none of them disappear while on-screen) however their widths still seem to fluctuate a bit.

Zooming in on the simulator does cause the vanishing lines to reappear - increasing the size of the app window does the same for the built app as well - thanks, Nick!

That’s most of my initial queries answered, however even when I’ve resized the app window to fill as much of my monitor as possible I’ve noticed that the corners of my rounded rectangles are still rough and pixelated. All my PNG files seem to be rendering fine and text looks alright as well. Any insight into the ugly rectangles?

Also, what’s the best-practise approach to building versatile apps that don’t have elements disappear when displayed on larger screens? Simply go for a lower resolution? Or is it possible to apply the mathematical rounding approach proposed in the link I posted to elements like listviews and rectangles?

Sorry for the barrage of questions. Cheers for the help.

#19

These are Corona’s rounded rects? Unfortunately the built-in shapes are of poor quality that are only fit for 480x320, you might have to roll your own rounded rects to get a quality result on desktop. Or perhaps RoamingGamer’s SSK2 has something like that built in?

#20

Desktop resolution options are defined in build settings, there’s some docs on here somewhere.

I think I just always used a strokeWidth of at least 2 to get round this issue.