Rounded rectangles: optimize and anti-alias

[zwim]

This is an optimization which depends on koreader/koreader-base#1738

---

This change is 

[poire-z]

(Don't forget to bump base with this PR for a self sufficient commit.)

[poire-z]

Please move this out of just in-between the somehow related xtext & rtl mirrorring :) ie. above near the "C blitter" thing, to which "antialias" sounds more related.
(I let @NiLuJe tell if it's worth having this toggable.)

[NiLuJe]

It looks to be fairly non-intrusive, so, eh, why not ;).

I'd make the label more precise though, because "UI elements" is kind of an overly optimistic generalization, given that it really only affects rounded corners ;p.

[zwim]

Is _("Anti-alias rounded corners in UI") good English?

[Frenzie]

Grammatically sure, but what purpose does "in UI" serve?

[zwim]

"in UI" should point out, that only the corners in our UI gets anti-aliased and not something else (like an image ...).

[Frenzie]

That strikes me as redundant (i.e., what other rounded corners would we even know are such a thing as rounded corners other than those we very explicitly know about because we draw them), but if you prefer. /shrug

[zwim]

No strong feeling. I can go with you for consistency (as you have texted much more than I ;) )

[poire-z]

I guess you want 1 and 0 so it is passed as-is to the C function. While true and false feels more like what we are used to in frontend - where we can use stuff to toggle/flipNilOrTrue that are better than this ugly 1 - old_val to switch between 1 and 0 :)
If there is only one call, you could just use there anti_alias and 1 or 0 which is how we do it nearly everywhere, ie. in credocument.

[poire-z]

logging to be removed :)

[zwim]

Before merging, could you please check if I did the bump base right.

[poire-z]

The base bump looks fine to me.

Just a space to remove at the end of this line
frontend/apps/filemanager/filemanagermenu.lua:630:64: line contains trailing whitespace

[poire-z]

Is it ok to pass a bool to paintBorder, where it will be passed to paintRoundedCorner() as anti_alias or 0, so true or 0 - and then to cblitbuffer.BB_paint_rounded_corner(..., int anti_alias) as anti_alias or 0.
(Not forgetting that in Lua land, the number 0 is true, not false.)
It may work alright, even if a bit non-obvious to grasp, and no need to rebump base - just want somebody else to check all is fine whether we pass initially anti_alias as true of false.

[NiLuJe]

It should be safe, yeah (c.f., Lua -> C for booleans in http://luajit.org/ext_ffi_semantics.html)

[zwim]

A good point.

(Not forgetting that in Lua land, the number 0 is true, not false.)

Yepp and anti_alias=0 or 0 gives 0 -> Which is a noop.

We have to pass a parameter to cblitbuffer.BB_paint_rounded_corner(..., int anti_alias), otherwise we get a runtime error.
In Lua land we want (your proposal) to pass nil, false or true.
If we hand over

• nil to paintBorder, anti_alias or 0 will expand to 0; in C-land 0 means false;
• false to paintBorder, anti_alias or 0 will expand to 0; in C-land 0 means false;
• true to paintBorder, anti_alias or 0 will expand to true; in C-land any value except 0 (most certainly uint 0xffffffff) means true.

If someone will hand over (in future)

• 0 to paintBorder, anti_alias or 0 will expand to 0; in C-land 0 means false;
• 5 to paintBorder, anti_alias or 0 will expand to 5; in C-land any value except 0 means true.

Of course, we can make all those considerations explicit, but then we have to change the blitbuffer API.
Keeping the proposed API means any value except 0 or false enables anti-aliasing. (And maybe in future different kinds of anti-aliasing ...)

[zwim]

@NiLuJe You are to fast for me ;)

[poire-z]

Thanks for your double checkings :)

[zwim]

In case someone wants to commit this PR, please don't squash.

[poire-z]

(Use "rebase" instead of "merge commit" next time, just to avoid a useless commit - still wondering what's the use for this stupid "merge commit".)