Checkbox Appearance #2

[RobLoach]

Follow up on #681 .

@awschult002 @riri I'm unsure if this fixes all the issues we had considered, but it may be onto something. Touches some of the base style settings, which may be what we were looking for.

SDL Renderer

RawFB X11

Note the rectangle misalignment on x11 raw

[riri]

@awschult002 @riri I'm unsure if this fixes all the issues we had considered, but it may be onto something. Touches some of the base style settings, which may be what we were looking for.

Agreed, that was the goal of my comment: it's not perfect but leading to improvements for a nice change with checkboxes and options.

I admit I get lost with all the PRs stacking for this feature.
I let you unroll the mess with opened PRs and issues once it's merged lol

[RobLoach]

Yeah, it's tricky because I think we're so close to getting it right across the renderers, but there's still something wrong, and I'm not 100% sure what the original cause is. Apologies for the PR spam.

[awschult002]

i think we should make an issue that RAWFB demos have strange checkbox, link that here for tracking; then merge the PR.

That will clean up the PR mess that i started; but keep some tracking around of the problem so that we can keep working it. I like the idea of letting the issue pages balloon, while keeping the PR list small and clean

[riri]

Agreeing with that, making an explicit issue denoting the backends on which draw issues persist.
Letting @RobLoach deciding.

[awschult002]

i am going to post this here, but will migrate it to issue when that is created.

I spent some time really trying to figure out the issue of this rawfb checkbox in my PR #681 , but couldn't figure it out. HOWEVER! I believe I found a significant clue.

The shape of the internal box changes depending on whether you have rounded corners or not. What I mean is the offset problem we are seeing changes. Here is what the offset looks like in the "normal" execution path where in the internal rectangle is filled without rounding.

notice that the inner rectangle is bias into the upper left corner (0,0).

now take a look at the exact same thing, but with the do_toggle rectangle draw function asking for the same rectangle with rounding set to 1 instead of 0.

it is a little difficult to see, but the box has shifted down to something more like (0,+1). This has lead me to investigate how the rectangles are actually drawn. If you don't use rounding, then a scissor algorithm is used, and if rounding is added, then arcs and lines are used. I played around with this a little bit and... as of this moment, I believe the issue to be with how we are drawing the scissor and basic primitives. basically. i think the issue is something like

/* draw rectangle no rounding */
for( i = 0; i < h; i++)
{
      stroke_line(i++)
}

Where in we loop to h EXCLUSIVE; but a height and width number might be considered an inclusive value.

I haven't solved the problem; but I believe the bug is something very akin to what I have noted above and it exists in nuklear_rawfb.h which is why all of the rawfb have the issue and nothing else.

[RobLoach]

Definitely onto something! Could it be that, in some renderers, lines are drawn differently depending on line thickness? Like you touched on at...

        } break;
        case NK_COMMAND_RECT: {
            const struct nk_command_rect *r = (const struct nk_command_rect *)cmd;
-            nk_xsurf_stroke_rect(surf, r->x, r->y, NK_MAX(r->w -r->line_thickness, 0),
-                NK_MAX(r->h - r->line_thickness, 0), (unsigned short)r->rounding,
+            nk_xsurf_stroke_rect(surf, r->x, r->y, r->w,
+                r->h, (unsigned short)r->rounding,
                r->line_thickness, r->color);
        } break;
        case NK_COMMAND_RECT_FILLED: {

Perhaps if there's a line thickness of 2, it should be * 0.5 the line thickness x position?

[awschult002]

i would love to continue the discussion, but am afraid to keep posting here if in we get an issue where this investigation could continue.

[riri]

I just checked last version and it seems to work pretty well @RobLoach, on x11, x11_xft, xcb_cairo and rawfb/x11.

I didn't realize rounded corner disappeared in a previous commit, but this fixed it's not an issue.
Maybe a future PR could give the option to style the roundness or checkboxes ;)

With an updated patch version for nuklear (toggle changed) in clib.json and CHANGELOG, all seems ok to finally merge this so awaited evolution!

[awschult002]

Yes. The rounded corners were removed because it made the issue look much worse. Rob and I discussed it in our other PR.

[rswinkle]

I want to chime in since I ran into something several weeks ago that I've been digging into a bit. I think it might overlap slightly with the checkbox issue.

So the picture below is a screenshot of screenshots of a very simplified SDL_renderer demo program, just a window that fills up the entire screen with a single labeled checkbox, ie:

        if (nk_begin(ctx, "Demo", nk_rect(0, 0, WINDOW_WIDTH, WINDOW_HEIGHT),
            NK_WINDOW_NO_SCROLLBAR))
        {
            nk_layout_row_dynamic(ctx, 0, 1);
            nk_checkbox_label(ctx, "check", &check);
        }
        nk_end(ctx);

This resulted in these screenshots:

The screenshot is divided with anti-aliasing on on the left, off on the right, and using a HW accelerated renderer on the top and a software renderer on the bottom. I noticed the windows not reaching the edges issue for software rendering about a month ago. There's also the slight shadow effect on the right and bottom of the checkbox which I only noticed from all the work I've done lately on the backends running the demos that don't have that.

After verifying that neither problem appears when using a HW accelerated renderer I chalked it up to some rounding/truncation code in SDL2 which may or may not be considered a bug in SDL_DrawGeometryRaw() and probably isn't technically an issue in Nuklear.

Then today I was looking into Nuklear some more because I was (and still am) a bit confused about how/why it was generating so many triangles even when I drew an empty window with no border or title etc.* and seeing some AA stuff in there reminded me that's another variable to try.

So to bullet point my findings:

• Different results when using software vs hardware renderer is SDL
• In SW with AA, windows (or panels in general?) are 2 pixels short on the right and bottom edges and possibly related,
• the checkbox has a shadow/embossed look on the right and bottom.
• Turning of AA fixes both of those, the window and the checkbox grow, but the left side is narrower when checked
• For HW with AA looks the best at least as far as none of the obvious issues
• For HW without AA the boxes are taller and again has the left side narrower when checked

I can make a gist of the modified program if anyone wants.

footnote: FTR, turning off AA does reduce it to a single pair of triangles but I still don't understand why do anything different for rectangles? Aliasing is only a problem for diagonal edges so knowingly adding it to straight edges seems wasteful and not even visible when it's only a pixel thick, but I haven't really grokked all of the code so maybe I'm missing something.

[awschult002]

I am ashamed that the thought never occurred to me to use a background of a contrasting color.... I just been straining my eyes this whole time

[rswinkle]

I am ashamed that the thought never occurred to me to use a background of a contrasting color.... I just been straining my eyes this whole time

Honestly you shouldn't feel bad. I've missed it for about 6 years on my own project. It's only 2 pixels on the bottom and right and I almost always had (transparent) gray on black. 2 things finally made me notice it, one, some bright images in the lower right in thumb mode making a clear contrast and subpanels/groups reaching the bottom of the screen but having a few black pixels between them (window spacing/padding) where the main window background didn't reach the bottom, especially obvious during window resizing.

Also I noticed something else just after I posted. The problem of the left side of the checkbox being thinner (for all but HW_AA) disapears for the second checkbox in a row:
SW no AA

SW AA

HW no AA

HW AA