changes for blit refactor to bitmaptools.

[FoamyGuy]

These changes go along with #8136 in the core.

I made icon_animated fully backward and forwards compatible with hasattr logic. For flip_input, there were several locations which needed updating so I opted for something more concise in leaving a comment with the prior version and adding the new version below.

I'm open to other options as well. If there is a desire to forego backwards compatibility altogether, or a preference to make flip_input use the logic to be compatible without switching commented lines.

[jposada202020]

My two cents...
We could use os.uname() to identify the CircuitPython Version, but it will get us to kind of the same as you did with the comments.
For me, if the examples are in the learning Guides I will go Backwards compatible, if not breaking changes :)

[FoamyGuy]

I tried implementing the fallback logic for flip_input today but I'm running into ValueError: y1 must be 0-11 issues. It seems like flip_input tries to blit outside the valid range. I dug for a while but have been unable to find the correct fix yet, need to circle back to it again later.

[FoamyGuy]

The flip_input test script works successfully on 7.3.3 but fails on 8.0.0. Somewhere in between there it seems there was a change in the core that was never handled in this library.

When I come back to this I'll try to narrow it further and figure out what the specific core change was. Also worth looking into the history of BitmapLabel. This library was trying to access bmp_label.tilegrid but that isn't a valid property, I think it was made "private" by renaming to bmp_label._tilegrd. Perhaps it should have remained public, or perhaps there is some other difference that could be causing the trouble with flip_input. For my testing today I used bmp_label._tilegrid in the code.

[FoamyGuy]

8.0.0-rc.0 is the first version where this fails
This is the stacktrace:

code.py output: Traceback (most recent call last): File "code.py", line 92, in <module> File "/lib/adafruit_displayio_layout/widgets/flip_input.py", line 539, in value File "/lib/adafruit_displayio_layout/widgets/flip_input.py", line 417, in _update_value File "/lib/adafruit_displayio_layout/widgets/flip_input.py", line 688, in _animate_bitmap File "/lib/adafruit_displayio_layout/widgets/flip_input.py", line 572, in _draw_position ValueError: out of range of target 

[FoamyGuy]

I've found some more information about this:

While it did run without crashing on 7.3.3 it wasn't actually "functional" it turns out. The intention for flip_input is to animate the text when changing between items in the list. At 7.3.3 it doesn't animate but rather blinks to invisible and then comes back again showing the new number. Basically the animation isn't being shown but the change to numbers does occur just with a blank gap inbetween instead of the animation.

The most recent version where flip_input actually worked with it's intended animation is 7.0.0-alpha.3. Starting in the release after that (alpha.4) the blink to blank occurs as described above instead of the animation.

Everything noted above applies specifically to vertical orientation flip_inputs. I have not found any prior version where the horizontal flip_input animation is working successfully, it could have to do with library versions in the mix as well I do believe I have seen it work in the past so I think it must've at some point. Every version that I try now is raising an out of range of target error or the newer slightly reworded version of the same error.

As far as I can tell the crux of this issue is values either less than 0, or greater than target_bmp.width are being passed to one or more of the arguments to the calls to blit() in some situations. Current implementations of blit treat this as an error. I'm not certain yet if it used to be allowed or whether some other difference in versions is causing those values to differ.

The intended animation does include the old number "flying" up or down out of the visible frame and the new number "flying" up or down into frame and overshooting the final landing point slightly then snapping back. I could imagine a scenario where it used to be allowed to pass out of bounds values and blit() would accept them + "silently" skip any pixels that were out of the range but work successfully otherwise and if that was the case the code in flip_input could have been relying on that behavior.