Terry J. Reedy <[email protected]> added the comment:
65535 = 35536 - 1 = 256 * 256 - 1 == 255 * 257
On Windows, each r, g, b value is n * 257 for n in range(256) (see attached
file). The precision loss happens when colors are stored, before the division
in winfo_rgb. Perhaps 8 bits/channel (including alpha) is baked in.
Since divmod(n * 257, 257) = (n, 0) and divmod(n * 257, 256) = (n, n),
(n*257) // m = divmod(n*257, m)[0] = n whether m is 256 or 257.
---
macOS appears (from limited experiments) to handle 1 and 2 digits the same as
Windows (repeat 4 or 2 times): val('#a00') = val('#aaaa00000000') = 0xaaaa,
val('#ab0000') = val('#abab00000000') = 0xabab. 4 digits are left alone while
3 digits use the 1st as the 4th val('#abc000000') = val('#abca00000000') =
0xabca.
----------
Added file: https://bugs.python.org/file49756/tk_rgb.py
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue33289>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com