IOS Plus42 artifacts when all pixels on

[Andy]

I use the below program to create a solid black screen for inverted graphics.  It works fine on Plus42 Windows (a uniform black screen is created), but on my iphone and ipad I get artifacts (see attached image).

▸LBL B
HEIGHT
LSTO "H"
▸LBL D
RCL "H"
+/-
-1
PIXEL
DSE "H"
GTO D
SF 34
RTN
END

[Vincent Weber]

I've just tried on both my Android phone and my iphone.

On Android I got a solid black screen and on iOS I got artefacts, although not as pronounced as yours.

[Andy]

Thank you for verifying.  I find the pattern of the artifacts depend on the display resolution.  The attached image was 99 rows by 132 columns.

[Andy]

it also happens when running programs that have a lot of continuous black (see attached)

[Thomas Okken]

The MacOS, iOS, Android, and Linux versions all render the display by painting each black pixel separately as a tiny black square or rectangle. I chose this approach, rather than the more direct bitmap rendering APIs, because the latter perform smoothing when pixels are scaled up, causing the display to look blurry.

A side effect of rendering pixels as individual squares / rectangles is that you can see faint lines between the pixels. I actually kind of like this artifact, because it resembles a real 42S-style LCD. But of course the artifacts you're seeing in the screen shots above are not desirable. I'll have to look into using a different rendering method when pixels are very small.

Note that none of this affects the Windows version. The approach of painting individual pixels can't be used there, because the GDI+ API that I'm using doesn't support sub-pixel addressing, and instead I use bitmap rendering with resolution-dependent interpolation modes, and using an intermediate bitmap with increased resolution (4x4 pixels for each logical pixel) to reduce the smoothing-induced blurriness.

The best solution would probably be to use an intermediate bitmap sized just so that it corresponds 1:1 with the physical display pixels. That way I would have full control over the rendering process, and the final step of copying the bitmap to the display wouldn't involve any scaling at all, and thus wouldn't create any smoothing artifacts. But it would be a PITA to implement as well!

I'll have to think about this... I'm putting it on my to-do list. 

[Thomas Okken]

Correction: the Android version doesn't paint individual pixels either. Unlike the other platforms, the Android bitmap rendering API actually supports disabling all smoothing, so I can get crisp scaled pixels without needing any of the contortions mentioned above.

[Andy]

Thank you, Thomas.  My primary calculator in college was the HP48sx, proceeded by about 1 year on the HP28s, both of them have the faint lines between the pixels, and I have many good memories from those days and comp.sys.handhelds.

Andy