You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • @Gorden,

    that must be it... but it is obviously not that simple - and costs cycles / memory for code, and so far the differences were minimal to notice with the resolution and most sizes of shapes I used so far (For vector fonts it is though visible, because the font character's nooks an crannies are small shapes... assuming the same filling algorithm(s) is(are) used.)

    In my emulator I use canvas and have high resolution and rendering is differently / does alias(?) differently. (The 'bad' thing abut my emulator... or would you call that a simulator?). The difference I felt for drawing horizontal / vertical lines / squares / rectangles /along the x- an y-axes: not the pixel is the coordinate, it is the 'spot' between... because when I render a single pixle line on a coord that is an integer, it shows grey over two pixels... I added 0.5 and then it's different. Also drawing exactly the same line with the background color (black) over a previously white one (showing grey), it does not 'remove' / 'expunge' it: it just gets darker grey!

    For vector fonts I use a same sized font from the underlaying infrastructure (browser / os).

    For bitmapped fonts I though have same logic as Espruino but without scaling.

    I built the emulator/simulator(?) less for the exact look, but more for supporting development of logic, faster round-trips (no upload, slowing by BLE upload). extended debug and i(pseudo) independence from device. For a while I even had code in the project and module files that required by the emulation but were inert / no-ops when running on device. Lucky I got rid of that.


Avatar for allObjects @allObjects started