Revert "Init fix and performance improvement"

[Bodmer]

Reverts Bodmer/TFT_eFEX#12

New feature still has issues, reverting pull until these are resolved.

[tobozo]

Unfortunately none of my esp8266 builds work anymore with TFT_eSPI because the user setups have been deleted by TFT_eSPI updates :-(

As I'm not motivated to go into this pin assignation hell again, my test basis is limited to the Odroid-Go (ST7789), the M5Stack (ILI9341) and two models of WROVER_KIT with ST7789 and ILI9341 as well (four different User_Setups).

On the screenshot you provided earlier, the problem seems to be a conflicting initial orientation in the user_setup or in the defines of your ESP32 test board, and the effects of dynamically sizing the viewport so the example works on any correctly setup display. I can reproduce that by setting a bad TFT_HEIGHT/TFT_WIDTH in the defines of any of my displays.

As expected, if the display has a bad setup, the example code shows the symptom you captured.

Actually some examples bundled with TFT_eSPI also show these symptoms on my displays, I need to adjust something in the example code if I want to make them work (sometimes it's hardcoded width/height, sometimes it's an arbitrary orientation).

If these examples are part of the release package I don't see this as an issue, so what other issues are there that I should fix?

[Bodmer]

It is best to keep a backup of your setups before upgrading TFT_eSPI or put your files in a folder outside the library and call them from User_setup_select.h. I use a folder called "TFT_eSPI_Setup" in the library folder, then add a line such as this: #include <../TFT_eSPI_Setup/Remote_Setup_Select.h> The ../ means go up one directory level. You then keep all your setups in the TFT_eSPI_Setup folder and edit the Remote_Setup_Select.h to call up your own setups. This means that you only have to copy one single line into a newly installed copy of TFT_eSPI and add // to the default line. If you use PlatformIO you can attach setups to the sketch but that is not permitted in the Arduino environment :-(

Re. the gradient problem, my explanation is as follows:

1. The code changes in the push do not reflect your test setup as I get different results
2. In the pushed version the bug is that drawGradientHLine() and drawGradientVLine() functions must use:

    _tft->width()  not width()
    _tft->height() not height()

This is because TFT_eFEX is a different class. After this change my output is identical to yours. Though there are still some missing pixels.

[Bodmer]

I had a look at the code again, the reason for the missing pixels on the small circles is that you are using radial lines, It would be better to draw open (not filled) circles of the colour with a radial increment of 1. This may also be faster but you will need to create a simple sketch first to check if open circles leave any missing pixels. You can use the same linear interpolation method to derive the colour to use at any radius. If you draw large to small circles, you could use filled circles to guarantee no missing pixels and this may be faster than the line algorithm even though may more pixels get drawn. The advantage of the above is that calculations of the colour occur less often and the circle function from the TFT_eSPI library can be used directly. In the pie chart example I use radial triangles to avoid missing pixels but an algorithm for filled gradient triangles would be slightly trickier to implement due to the way the existing library algorithm works.