Right now this is as expected - it's what I'd mentioned before about having a slower but more capable fillPoly implementation. The current one works on a scanline basis - filling from lowest X to highest X.

Thanks

It's something I plan to improve at some point soon though - it'll likely decrease the rendering speed slightly but it definitely seems like a worthwhile addition.

Taken from the forums post

Example algorithm posted here: http://forum.espruino.com/conversations/341492/#15015802

It looks simpler than what's there already really!

It's simple because it doesn't work properly :/

Current code is here: https://github.com/espruino/Espruino/compare/fillPoly_irregular

I had to modify it so it handled the topmost Y coordinate correctly (eg when drawing a diamond it'd miss off the top), and then also had to add a 'slope' so that it could handle the duplicate corners that would then be produced.

However drawing vector fonts still results in something like this:

................................
................................
................................
..#####...............#####.....
..#####..............######.....
...#####............######......
....#####..........######.......
....######........#######.......
.....######.......######........
......#####......######.........
......######....######..........
.......######..#######..........
........#############...........
.........######.................
.........###########............
..........#########.............
...........#######..............
...........######...............
...........######...............
..........########..............
.........######.................
.........##########.............
........######..####............
.......######...#####...........
......######.....#####..........
......######......####..........
.....######.......#####.........
....######.........#####........
...######...........#####.......
...######...........#####.......
..######.............#####......
.######...............#####.....

This is because the vector font is (currently) made out of a bunch of regular polygons, and there appear to be issues where they join

Ok, now fixed. Looks like the code mentioned initially actually does a standard polygon fill thing, which is to not fill the top and right hand pixels so that if you put polygons against each other you don't end up with overdraw - which is why the scanline code refused to draw the top pixel

My hacks will likely cause problems with more complex polygons since i'm effectively duplicating vertices at the corners :(

Nice, many thanks

Ok, fixed with 4442951