Adding Generic Graphic Driver implementation

[Ellerbach]

Description

• Adding Generic Graphic Driver implementation.

Motivation and Context

• Related to .NET nanoFramework graphics improvement proposition Home#1231
• Following Adding generic display driver nanoFramework.Graphics#118.

How Has This Been Tested?

On a real device, with real screen.

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).

[TerryFogg]

Also, I didn't see an option for this condition, which if I hadn't needed to hack it with a current display I would not have thought it required
My Hack required an offset to the x and y for the waveshare pico-lcd1.14 display. It must be in the way it is wired up to the controller
bool DisplayDriver::SetWindow(CLR_INT16 x1, CLR_INT16 y1, CLR_INT16 x2, CLR_INT16 y2)
{

x1 = x1 + 40;
x2 = x2 + 40;
y1 = y1 + 53;
y2 = y2 + 53;

[Ellerbach]

bool DisplayDriver::SetWindow(CLR_INT16 x1, CLR_INT16 y1, CLR_INT16 x2, CLR_INT16 y2)

that is already existing in the screen class.

[TerryFogg]

No, I didn't write that comment to waste your time.
What it means is that when you choose 0 coordinate for x or y in the C# code when it gets to the controller a fixed offset is required.
The controller first visible pixel is at (40,53)

You may think this is a special case which is ok.

[Ellerbach]

The controller first visible pixel is at (40,53)

And this is where the screen properties are used. See all native drivers like this one for example:

nf-interpreter/src/nanoFramework.Graphics/Graphics/Displays/ILI9342_320x240_SPI.cpp

Line 242 in deacdf3

bool DisplayDriver::SetWindow(CLR_INT16 x1, CLR_INT16 y1, CLR_INT16 x2, CLR_INT16 y2)

And see the example of the M5STciC with the SST35S where the screen is smaller than the driver and it starts at x=52 and y=40: /~https://github.com/nanoframework/nanoFramework.M5Stack/blob/5e18fa4b7d95c0510ae201170da0fc4f010f7153/nanoFramework.M5StickCommon/Screen.cs#L63

I've added this feature quite some time ago. So that's the way to go to address your problem.

[josesimoes]

LGMT! Sure looks like a nice improvement.

(I have not tested it myself)

[josesimoes]

LGTM!
The 2nd target name it's a bit extended... 😅 but... 🤷🏻‍♂️