Oops, make sure we use the C bb on all the eInk devices...

[NiLuJe]

Note that it's still blacklisted on PB because of their crappy unreliable fb info on some devices, though ;).

So this will be mainly of interest to Cervantes & reMarkable (ping @pazos / @avsej; @tcrs)

---

This change is 

[NiLuJe]

I don't expect any trouble at all on reMarkable, because it's @ 8bpp, so it's essentially the same as on Kindle & Kobo.

But Cervantes is probably still @ 16bpp, and we didn't test that for very long on Kobo, because RGB565 is the worst.

[pazos]

So this will be mainly of interest to Cervantes ...

As far as I am concerned it works fine as is. I'm not too much interested in fiddling with my cervantes besides platform maintenance.

If you think it is good to have the same bb on all platforms or it can provide any benefit for cervantes users I think it is safe to merge. On the worst case we can revert it soon. 👍

[NiLuJe]

@pazos: Ideally, Cervantes would be switching to 8bpp like Kobo/reMarkable. It'll probably need some testing to have fbdepth behave because of NTX board quirks, though (unlike on reMarkable, where it turned out to be straightforward).

But, in the meantime, the C BB does have full RGB565 support.

[Frenzie]

@NiLuJe I never got the impression that the C BB was really any faster than the LuaJIT one? (Except on malfunctioning Android of course.)

[NiLuJe]

Try panning in an imagewidget ;).

…

On Sat, Feb 15, 2020, 14:37 Frans de Jonge ***@***.***> wrote: @NiLuJe <https://github.com/NiLuJe> I never got the impression that the C BB was really any faster than the LuaJIT one? (Except on malfunctioning Android of course.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1047?email_source=notifications&email_token=AAA3KZSOIZIDN5QVPPC6HH3RC7V2VA5CNFSM4KTYB5B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3KXGI#issuecomment-586591129>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3KZX2CEHKB7EJ3WZQSY3RC7V2VANCNFSM4KTYB5BQ> .

[NiLuJe]

The main gain is arguably in consistency: when the JIT is happy, everything's mostly fine (close/very close to the C perf), but when it isn't, it can be 2 to 10 times slower for no discernible reason.

That's mostly obvious when rotation is involved, or with RGB565, or with alpha-blending.

(Also, dithering is slower in the pure-Lua version, but that's probably mostly because everything's secretely a double ;p).

[Frenzie]

Try panning in an imagewidget ;).

It only seems to "pan" by swipes or something? I don't really use that one.

By "impression" I meant a touch more than just eyeballometric measurements (though not too much more), and I noticed very little meaningful difference. In your terms, probably "very close"/practically identical to "close" in some cases, but that last one not necessarily to the benefit of C… (The C one has been optimized better since.)

That's mostly obvious when rotation is involved, or with RGB565, or with alpha-blending.

Right, alpha-blending is the only one I noticed and/or recall. Probably didn't look into 16-bit too much if at all either.

[NiLuJe]

What I actively measured was blitting CRe's buffer to the framebuffer (i.e., page turns), as that's what I was mainly concerned with. The rest (alpha, image, dithering) is more of an observation than anything ;).