Custom page selection for paged display

[JohannesWilde]

I am currently using an SSD1306 128x64 display and trying to write to it using an Arduino Uno. Because 2kB of Ram and 1kB of image data leave too little for the rest of the functionality, I was happy to see, that this library enabled one to use a paged update approach.
As to further minimize the computational cost [as I am effectively trying to simulate an LCD Keypad Shield [16x2 Symbols]] and to be able to seperate updates of different parts of the display, I would like to select only a partial region of the display.
This is my proposal how to implement it - feedback and criticism is very welcome.

[olikraus]

I am always happy to see code contributions, but in your case I am not sure whether this should be merged...

1. You mentioned 16x2 displays. For this purpose I suggest to use u8x8 with a suitable font. Why using u8g2 for this purpose?
2. You have introduced a new function customPage(), I do not see the need for this, because setBufferCurrTileRow will exactly do this.
3. The behavior of customPage(), I mean the related code is a little bit strage. It is not documented, and the add on over setBufferCurrTileRow() seems to be minimal. Whether it will work or not is also not clear to me. Compared to your procedure, I tried to document the functions as good as possible: https://github.com/olikraus/u8g2/wiki/u8g2reference#setbuffercurrtilerow
   I also created an example for this: https://github.com/olikraus/u8g2/blob/master/sys/arduino/u8g2_page_buffer/UpdatePartly/UpdatePartly.ino
   One more problem is the u8g2_ClearBuffer() call in your code, which will make the code more complicated than required. Especially, you can not draw your text and then call customPage() because of the risk of erasing of the page. Instead the sequence must be (a) call to customPage() then (b) drawing to the page and (c) sending the buffer to the display. This sequence is not clear to the end user.

Alll in all I think everything can be achieved with the existing functions and there is no need to extend this lib.

https://github.com/olikraus/u8g2/pull/990/files#diff-9585af394aba7eeeaefd11956f30cb35R119

[JohannesWilde]

Thanks for the fast reply. As for your points:

1. I wanted to not use the 16x2 character LCD display, but the much smaller 128x64 pixels OLED display I bought. And yes, I could write text using u8x8. But if I understood the limitations of u8x8 correctly, all printable characters will have to be 8x8 pixels in size.
   I wanted to rather choose an 8x13 font and also draw lines and potentially other things - which all should not have to be page-aligned [meaning of 8 pixels in size].

2. I agree that setBufferCurrTileRow() will do something similar. But I, as someone did with the already existing specialization "u8g2_FirstPage()", wanted to split the display in buffer-page-sized sections, as to be able to individually update them, in my case:

header [16 pixel height]

simulated 16x2 character display [34 pixel height, 13-pixel high font]

footer [16 pixel height]

Sure, I could manually calculate the first row of each section - but as there already were some methods thinking in terms of pages [u8g2_FirstPage(), u8g2_NextPage()] I thought, why not extend that interface.
But maybe I am too little into microprocessors and too much into C++ programming, so that I underestimate the additional cost [memory, calculations?] of these additional methods.

3. If the missing documentation is the problem, I would gladly write some, similar to the one you pointed me to in your previous answer.
   I could also provide you with a working example [at least, regarding the code].
   And lastly, that one should call customPage() before calling filling the buffer stems from it's origin from firstPage(). I intended it to be used something like the following:
   if ( display->customPage(PAGE_OFFSET_FOR_TEXT) ) { for (uint8_t pageNumberRelative = 0; pageNumberRelative < PAGES_USED; ++pageNumberRelative) { u8g2Display_->drawStr(x0, y0, text0); u8g2Display_->drawStr(x1, y1, text1); u8g2Display_->nextPage(); } }
   as to not break the already existing scheme for using firstPage() and nextPage().

I agree with you, that everything can already be achieved with existing functions - I thought of it more as 'convenience methods'. And for my - I must admit, rather special - case, quite useful.

If you would like me to elaborate some more, please tell me so.
If you don't think, I can persuade you, to see this as an useful addition, please tell me so.

In the case that I could convince you, I - as I said before - will definitly write some documentation and a minimal working example.

I hope, this isn't too much text - thanks four all your time.

Johannes

[olikraus]

But if I understood the limitations of u8x8 correctly, all printable characters will have to be 8x8 pixels in size.

it is possible to have glyphs which are multiple of 8. This means a font with 8x16 is very much possible (and also such a font is provided).

If you would like me to elaborate some more, please tell me so.

While reading your reply these are my thoughs:

How much convenience code should be part of a library? We can always extend the interface or we can create a powerful example. And it is always a question, whether to add a lib procedure or just create an example, which is based on the existing procedures. The risk of adding a lib procedure is to have a specialized function which can be used only to solve a very special problem. In such a case I often try to create a more complex example to show how this can be solved with the existing functionality.

The other question is: What is the problem you want to solve? Maybe a good documented example file would be much better for the u8g2 users?
The example could describe the problem and showcase how the problem is solved.
The example could introduce some helper function on how this problem could be solved.