I'm still milling in my head the fill poly issue. It is about rounding when it comes to low resolution - like in pixlejs. In non-graph-math language, it matters where the last point was relative to the new point and what the x/y delta is and the absolute pos in the (max) grid for the character. My gut then tells me that there is no general rule that can be right since character / symbol recognition by human is not following how math would simplified do... it depends on the symbols the reader knows and is trained to read even when not perfectly shaped or only partially visible / printed (I experienced that myself in recognition training in armed forces... and you may have noticed that to: for example, if you are into cars, you do not need to see much of a car and you know exactly what make and model - and even year - the care is you 'see'). In the font world think about the the 2x3 numeric font... it work for the digits 0..9, but if it would have to work for hex 0-9a-f, it fails for humans, even there is 64 (63) combinations 2 power number of dots|bits (-1) available. I tried to make some of the chars in 4x6 fonts better recognizable, like the & and the @ which show the most lines in x or y direction, for which there is not enough pixels to separate the lines.
The issue with fill poly is though not down to a few pixles. I tried to draw a beveled rectangle - a poly with corners beveled and then also rounded (2..3 bevels - with different angles - so to speak) on pixlejs, What bothered me that even with rounded and correct data, either the x max or min or y max or min corners would not render the same way. Just drawing - not filling - which happens with 1 pixle wide lines works perfect / create perfect corners - perceived 45 degree beveled or rounded (2 or 3 lines w/ different angle). To see yourself what I mean, take a look at [post #5(http://forum.espruino.com/comments/15012813/) in conversation titled g.fillPoly bug? for about 5 months ago (pic repeated below).
I agree that there is no general rule that will always feel "right".
45 degree edges in particular are ambiguous because the edge will always pass directly through the center of each pixel. Take the first square in the attached image, with two triangles sharing an edge - should the pixels along the edge (marked in yellow) be part of the first triangle, or the second?
One way to remove the ambiguity would be to offset the edge by a fraction of a pixel, as shown in the second square - but that would require fillPoly to accept fractional coordinates.
© Espruino, powered by microcosm.
Report a problem