Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arcs on dselector are too thin #246

Open
decentjohn opened this issue Jun 2, 2022 · 13 comments
Open

arcs on dselector are too thin #246

decentjohn opened this issue Jun 2, 2022 · 13 comments

Comments

@decentjohn
Copy link
Contributor

decentjohn commented Jun 2, 2022

The left and right arcs are slightly too thin.

I think this is simply how Tk draws them, compared to vertical/horizontal lines.

One fix is to add +1 to the width of the arcs:

			if { $radius1 > 0 } {
				lappend ids [$can create arc $x0 **[expr {$y0+$radius1+1.0}]** [expr {$x0+$radius1+1.0}] $y0 -style arc -outline $colour \
					-width [expr {$arc_width+1}] -tags [list ${main_tag}-nw {*}$tags] -start 90 -disabledoutline $disabled -state "hidden"]
			}
			if { $radius2 > 0 } {
				lappend ids [$can create arc [expr {$x1-$radius2-1}] $y0 $x1 [expr {$y0+$radius2+1}] -style arc -outline $colour \
					-width [expr {$arc_width+1}] -tags [list ${main_tag}-ne {*}$tags] -start 0 -disabledoutline $disabled -state "hidden"]
			}
			if { $radius3 > 0 } {
				lappend ids [$can create arc [expr {$x1-$radius3-1.0}] $y1 $x1 [expr {$y1-$radius3-1.0}] -style arc -outline $colour \
					-width [expr {$arc_width+1}] -tags [list ${main_tag}-se {*}$tags] -start -90 -disabledoutline $disabled -state "hidden"]
			}			
			if { $radius4 > 0 } {
				lappend ids [$can create arc $x0 [expr {$y1-$radius4-1.0}] [expr {$x0+$radius4+1.0}] $y1 -style arc -outline $colour \
					-width [expr {$arc_width+1}] -tags [list ${main_tag}-sw {*}$tags] -start 180 -disabledoutline $disabled -state "hidden"]
			}

You can see how this looks if I change just one part of the arc:
Screen Shot 2022-06-02 at 4 03 00 PM

doing it to the 4 arcs fixes the appearance:

Screen Shot 2022-06-02 at 4 09 20 PM

I noticed that even when I drew with a thicker -width, the arcs were still off by one:
Screen Shot 2022-06-02 at 4 05 21 PM

I'm not sure if this is how you want this fixed, or prefer another method?

@ebengoechea
Copy link
Collaborator

@decentjohn Are the captures from tablet or PC/Mac?

The corners are coded to have one pixel less than the sides, intentionally, because this is how they looked best when using thin borders on my Teclast tablet. Having them the same width showed them too wide, not matching the sides lines. But this was different on my PC (which was better when using the same width for sides and corners), so I prioritized the tablet case.

It is my suspicion also that this may depend on the specific width values being even or odd in the target resolution, as they are specified in a bigger resolution and then rescaled. So, rounding may produce different results in different resolutions.

@decentjohn
Copy link
Contributor Author

Yeah, this might be an artifact of anti-aliasing and might look different at other resolutions.

Here is a picture from my Teclast:
Screenshot_20220602-172514

Note that I'm not specifying -width -- the default is active.

I will try to double resolution and see.

@decentjohn
Copy link
Contributor Author

decentjohn commented Jun 2, 2022

At 2560x1600 it's still looking good, though there is a "darkness" to the arcs that isn't on the lines. I'm assuming that's a downscaling artifact caused by the antialiasing.

Screen Shot 2022-06-02 at 5 27 20 PM

@decentjohn
Copy link
Contributor Author

Could you look at the arcs on your tablet again, and see if they indeed do seem right on your teclast tablet or too thin? I have the patch above to +1 the thickness, but it sounds like where I put the change is suboptimal, as you -1 it somewhere else?

@ebengoechea
Copy link
Collaborator

@decentjohn
Is the change on nightly? It would be easier if you just comment the following lines (starting in line 6252) in proc rounded_rectangle_outline:

if { $width > 1 } {
    # Adjustment to look better under Android, that uses dithering
    set arc_width [expr {$width-1}]
} else {
    set arc_width $width
}

@decentjohn
Copy link
Contributor Author

I haven't committed my change, as I was waiting until we settled our conversation. I will switch to your method for this.

@decentjohn
Copy link
Contributor Author

Screen Shot 2022-06-08 at 7 53 10 AM

Done, and I switched to -width 2 for my dselectors, as the color change that dithering causes, goes away then. This looks nice.

@ebengoechea
Copy link
Collaborator

@decentjohn Is that capture from your tablet?

@decentjohn
Copy link
Contributor Author

this is from my teclast tablet, thickness looks good, darkness of color slightly different. I'm guessing that the "fix" would be to make the straight lines drawn with dithering. Do you know how to do that?

Screenshot_20220608-070930

@ebengoechea
Copy link
Collaborator

ebengoechea commented Jun 8, 2022

Not possible as far as I know. It seems the problems arise from different dithering behaviour between lines and arcs, and between platforms (PC/Mac/Android), but it is automatic, there's no argument for controlling it on canvas elements.

@ebengoechea
Copy link
Collaborator

This is how it looks in my tablet when using -width 3 (and commenting the code that removes 1 px from the arcs widths). It looks as if the arc width is one pixel wider than the lines, likely as a consequence of the dithering, and it's the reason I removed one pixel, as it makes the widths of the lines and arcs match better. This does not happen when the width is 1 px, and does not happen on PC neither (irrespective of the width value).
DUI_dbutton_outline_width3px

@decentjohn
Copy link
Contributor Author

decentjohn commented Jun 8, 2022

Here are photos of DYE settings and Misc Settings, off the Teclast, with the current code (ie, no -1 on width)

Definitely, the dithering color change is more noticeable on the blue lines.

Screenshot_20220608-094332
Screenshot_20220608-094133

@decentjohn
Copy link
Contributor Author

As an aside, we probably should decide on default colors to use for the dui buttons and use them in a consistent way. I'm fine with "blue=tappable" as you have done with "Use default color"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants