The clip rectangle is a way to constrain all of the graphic primitives to only draw in a desired location, likewise the Origin allows you to offset all of the graphic primitives. So in theory you could write your display code for some object, example button, starting at 0, 0... This code came from the member Blackketter as a PR to the main library. I integrated it first into my fork...
There are a couple of different ways/reasons I may use this in my own projects using this, like maybe if I have a button object, and I wish to use a font to draw buttons, I would maybe use the Opaque font drawing code, which will draw the background for each character through the full spacing of the character, including where to start the next character and to the start of the next row of text. This likely would extend lower than I would want in a graphical element like button, so I would probably set a clipping rectangle as to keep it from extending too low. Likewise if I am only going to update a small portion of the display and I am using Frame buffer, then I might set up the clipping just before the updateScreen as to make the update as quick as possible...
Now the question can simple frame buffer stuff be extended to other displays... Yes, there is no real magic here. In the simplest of cases, you can have Adafruit_GFX do most of the work for you starting off. That is all of the graphic primitives by default will funnel to calling drawPixel(x, y, color) for each pixel.
In my current stuff this is implemented like:
Code:
void ILI9341_t3n::drawPixel(int16_t x, int16_t y, uint16_t color) {
x += _originx;
y += _originy;
if((x < _displayclipx1) ||(x >= _displayclipx2) || (y < _displayclipy1) || (y >= _displayclipy2)) return;
#ifdef ENABLE_ILI9341_FRAMEBUFFER
if (_use_fbtft) {
_pfbtft[y*_width + x] = color;
} else
#endif
{
beginSPITransaction();
setAddr(x, y, x, y);
writecommand_cont(ILI9341_RAMWR);
writedata16_last(color);
endSPITransaction();
}
}
So the beginning part is the part that uses the origin and clipping rectangle.
Then in the Frame Buffer mode, we simply save away the color into a logical two dimensional array. Again I was not the first one to do this. Frank did this in his DMA version of the code. In his code it was actually a two dimensional array. in my case I emulate it with a one dimensional array, as to allow me to have the code handle orientating the display in the 4 rotations. But it simply saves it into the _pfbtft array in the appropriate place.
You could easily start off with just that or you could do like the ILI9341_t3 (and t3n and dma) libraries and overwrite several of the other virtual functions, like drawFastVLine, drawRect... If one wanted to only support the FB mode, you could simply copy the code that is in the #ifdef ENABLE_ILI9341_FRAMEBUFFER and remove the tests for _use_fbtft...
The only other thing you then need t do is to handle the updateScreen code. Note this code is more or less a duplicate of the code writeRect and would of course differ for each display...
Hope that helps. Also if desired may want to continue on another thread... As sort of off the topic of the main ili9341_t3 library