SmartMatrix addition: version information + consistent layer API

[mrwastl]

@embedded-creations:

i'd have two suggestion for smartmatrix:

• would it be possible to add a version information? (#define's) eg: #define SMARTMATRIX_VERSION_MAJOR 3 #define SMARTMATRIX_VERSION_MINOR 1

  plus optionally: #define SMARTMATRIX_VERSION_BRANCH colourspaces

• (public) access to layer buffer or pixel information for all three layer-types

  • background layer has:
  • RGB* backBuffer()
  • const RGB readPixel(x, y)
  • RGB* getRealBackBuffer()
  • scolling layer has:
  • `uint8_t* scollingBitmap;
  • indexed layer has:
  • nothing :(

  at least access to the bitmap information for all three types would be fine, readPixel() would be even better. especially indexed layer is missing this functionality.

background:

i'm currently developing a framework on top of smartmatrix3 that uses panes for displaying information - and these make heavy use of sm3's layer drawing functions.

the defines would be handy for en/disabling features in the framework according to the smartmatrix-version/branch used.

the API of my new toy is currently stabilising and i hope that i'm able to release a somewhat usable version at github soon.

[embedded-creations]

Great suggestions

Version: I think I'll probably add the version numbers, and if you want to track branch, you can add that to your branches (and use #ifndef to detect a main release).

Buffer access: If I added readPixel() for the indexed layer, would you want direct access to the bitmap as well?

[mrwastl]

sorry for the delay. too much to do, too little time.

track branch: yes. but you as the maintainer can set/force the names of the defines :)

buffer access: readPixel would be the best and correct way to access the buffer, but a pointer would be faster ... inheritance isn't necessary (no readPixel() for Layer-class) and would be a little problematic i guess (bool vs. RGB-colour vs. index of colour)

why do i need access to the colour information: i use some drawing-methods in panes that are smaller than the lcd panel display (i can draw text or other stuff into these without drawing outside of the pane area). these panes can draw information (sensor, text messages, ...) and are then copied into the main matrix layers.

also copying indexed layer panes into the background layer matrix layer will then be able (if access to indexed layers buffer information will be available).

question: are you planning to add more planes to indexedlayer? at the moment: one plane (two colours). but parts of the API of indexedlayer would already be prepared to use depth=1/2/4/8 (well, then readColor() would be nice to either return the colour index or an RGB-struct).

[embedded-creations]

same here...

track branch: yes. but you as the maintainer can set/force the names of the defines :)

yes, but I can't force someone to use the defines in their branch. I think if I put a define in the release branch, it will end up unchanged in other people's branches. I don't think I will add this to the release branch.

i use some drawing-methods in panes that are smaller than the lcd panel display

What if we added width, height and x/y offset to the Layer class, and you could create a layer that was smaller than the full display? Would that help with what you're trying to do? I considered that from the start, but it didn't make the 3.0 release.

question: are you planning to add more planes to indexed layer?

I'm not sure I'm following the plane terminology, but I do plan to increase the color depth of the indexed layer to support 2 and 4-bpp in the future. For 8-bpp I'd probably just use your RGB8 support with the background layer. If you want a RGB8 layer that supports transparency, I think it would be best to build that on top of background, not indexed.

[ecurtz]

There's a slightly more complete version of indexed layer with basic support for different index sizes in my fork.

[mrwastl]

back from a little trip to stockholm - they really seem to be into rgb matrix displays. shops, arena, info displays, everywhere. several sizes (small to really huge) and geometries (banners, video, ...).

seems that such matrix-walls are getting more common and cheaper and cheaper ...

@ecurtz: seems interesting. i think that i will test indexed layer stuff with your branch. maybe SM_INDEXED_256_COLOR isn't necessary if RGB8 is used. and access to the backbuffer has to be added too ..

@embedded-creations: 'create a layer that was smaller than the full display': one reason for panes with own backbuffer is that if you write a string to a layer or draw something onto these you don't have to care about drawing out of bounds. i will add support for panes without backbuffer, but such a pane will have the disadvantage that it could also draw out of bounds. if you plan to add and x/y-offset + w/h AND precautions, that, if you draw something, it will stay inside these bounds, than this would help a lot.

8-bpp: yes. with RGB8 8-bpp indexed layer would no longer be necessary.