audit use of parseInt
#505
Comments
|
Yes. Would help a lot as well if we could gather some unit tests that can be tested against while fixing these. |
|
I also wanted to know if there was a way to get (native) screenshots of the Selenium render tests, so we can see exactly why some tests have very low render accuracy on certain browsers? |
|
The webdriver tests actually compare native screenshots with the html2canvas renders (that's what the percentage on the https://travis-ci.org/niklasvh/html2canvas results refer to). I've been meaning to have some API setup so the screenshots could be stored and viewed after each commit as well, since computer image matching isn't very reliable here. |
|
Yep, by getting the native screenshots I meant viewing those produced by the webdriver tests, alongside the h2c renders if possible (and/or maybe an image diff?). :] That would be extremely valuable, I think. |
- Updates CSS color stop regular expression to accept color names - Handles arbitrary gradient direction percentages - Handles certain CSS2 linear gradients (fixes Firefox). Ref niklasvh#469. TODO: - add support for px (see CanvasRenderer.prototype.renderBackgroundGradient) - update regexps to support floating point numbers (see niklasvh#505) - add tests
- Updates CSS color stop regular expression to accept color names - Handles arbitrary gradient direction percentages - Handles certain CSS2 linear gradients (fixes Firefox). Ref niklasvh#469. TODO: - add support for px (see CanvasRenderer.prototype.renderBackgroundGradient) - update regexps to support floating point numbers (see niklasvh#505) - add tests
- Updates CSS color stop regular expression to accept color names - Handles arbitrary gradient direction percentages - Handles certain CSS2 linear gradients (fixes Firefox). Ref niklasvh#469. TODO: - add support for px (see CanvasRenderer.prototype.renderBackgroundGradient) - update regexps to support floating point numbers (see niklasvh#505) - add tests
|
Considering the lib has been rewritten, most of these should be fixed |
There seem to be many places in the code where
parseIntis used whereparseFloatmight be considered more appropriate/correct. This can result in certain rounding errors and blurry renders, as mentioned in, for example, #340 (relevant comment).It should also be noted that, according to the spec(s), pixel (and most other length/position/dimension/number) values can be floating point numbers, so any regular expressions used to parse number values should probably also be audited to ensure they're checking for a possible decimal part, where appropriate.
The text was updated successfully, but these errors were encountered: