Export BitmapData.read

[ninovanhooff]

LCDBitmap.get(x,y) is very slow to sample pixel data, presumably because it extracts the bitmap data on every invocation.

When caching the BitmapData with LCDBitmap.getData and then invoking read on the BitmapData, we can sample pixel data at 93x the speed of LCDBitmap.get(x,y)

benchmark, invocations per 100 ms. Higher is better:

LCDBitmap.get(0,0) - 513
BitmapData.read(0,0) - 47716

[samdze]

Right, a way to get/set pixel data in a more performant manner would be welcome.

The read template is meant to be private, but only because there's BitmapView (type BitmapView* = DisplayFrame | BitmapData) that implements all the methods valid for both DisplayFrame and BitmapData.

So, an efficient (and unsafe? Right now get and set/clear do many safety checks) way to access pixel data should be added to BitmapView!

Maybe @Nycto has been doing something similar to optimize performance on his game?

[Nycto]

Ah, yes! I actually have a function for bulk setting pixels that is much faster. It’s not super optimized, but it’s a lot faster than manually setting each pixel.

I’ll submit a PR

[Nycto]

In terms of this specific CR, exposing read has two downsides:

1. it doesn’t do bounds checking. My subjective opinion is that it should be done as an assert so it disappears in release mode.
2. read returns the whole byte, so the users of still need to do their own twiddling to extract the actual coordinate they are looking for. This should be the job of the library, imo

[Nycto]

A PR with the faster bulk pixel setting code: #26

[ninovanhooff]

For reading, I just discovered that get(x,y) can also be used, because BitmapData is a BitmapView and proc get*(view: BitmapView, x, y: int): LCDSolidColor

It seems plenty fast, so I guess that existing function covers the reading scenario?