Possibility to draw lines with thickness, similar to drawWideLine in TFT_eSPI

[jgauchia]

In the TFT_eSPI library, there is the possibility to draw lines with thickness using drawWideLine. Is there an alternative in LovyanGFX?

Thank you.

[tobozo]

Hi,

I tried to replicate Bodmer's drawWideLine, but found out TFT_eSPI version is limited in terms of color input types (e.g. it doesn't handle rgb332 or rgb888) and filling options, so I extended it with gradients, which also enabled the creation of a couple other features such as radial gradient fill for {rect,circle}, all working seamlessly with rbg888, rgb565 and rgb332 color types.

I will try to submit a PR once I'm done with polishing the code but this feels like feature creep and I'm not sure how to contribute that to LovyanGFX without creating a tech debt, maybe as a snippet in the src/lgfx_user directory, or as an include with an example sketch?

[jgauchia]

Ok, looks good!

[tobozo]

hi @GOB52 @lovyan03 can we discuss the best way to contribute these features to LovyanGFX/M5GFX?

https://gist.github.com/tobozo/cc379ae025391f64d69fb633f383c491#file-lgfx_wideline-hpp

Possible integration strategies:

• Full separation: create a new example sketch based on the gist
• Partial integration: create src/lgfx_plugins/lgfx_wideline.hpp as an optional include
• Full integration: move the functions to LGFXBase

@jgauchia if you want to play with the features just download the gist but keep in mind it's not the final version.

COLOR can be any of uint8_t, uint16_t, uint32_t, RGBColor, lgfx::rgb888_t, lgfx::rgb565_t or lgfx::rgb888_t.

However the best performances are obtained using lgfx::rgb888_t.

Draw thick+smooth lines with single color fill

void drawWideLine(LovyanGFX* gfx, int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick, COLOR fg_color)

Draw thick+smooth lines with gradient fill

void drawWideLine(LovyanGFX* gfx, int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick, const colors_t<COLOR> gradient)

Draw wedge line with single color fill

void drawWedgeLine(LovyanGFX* gfx, int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick0, float thick1, COLOR fg_color)

Draw wedge line with gradient fill

void drawWedgeLine(LovyanGFX* gfx, int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick0, float thick1, const colors_t<COLOR> gradient)

Fill smooth circle with single color (redundant with lgfx::fillSmoothCircle)

void drawSpot(LovyanGFX* gfx, int32_t x, int32_t y, float radius, COLOR fg_color)

Fill smooth circle with gradient

void drawGradientSpot(LovyanGFX* gfx, int32_t x, int32_t y, float radius, const colors_t<COLOR> gradient)

Fill rect with radial/linear dual color (fill_style_t can be any of RADIAL, HLINEAR or VLINEAR)

void fillGradientRect(LovyanGFX* gfx, int32_t x, int32_t y, uint32_t w, uint32_t h, COLOR start, COLOR end, fill_style_t style=RADIAL )

Fill rect with radial/linear gradient (fill_style_t can be any of RADIAL, HLINEAR or VLINEAR)

void fillGradientRect(LovyanGFX* gfx, int32_t x, int32_t y, uint32_t w, uint32_t h, const colors_t<COLOR> gradient, fill_style_t style=RADIAL )

Create a gradient

colors_t createGradient( COLOR[] colors )

colors_t createGradient( COLOR* colors, uint32_t count )

Example:

GradientPluginAdapter gfx(&tft);
uint16_t colors[] = { TFT_GREEN, TFT_YELLOW, TFT_ORANGE, TFT_RED };
auto gradient = gfx.createGradient( colors ); // create a gradient item
gfx.fillGradientRect( 10, 10, 200, 200, gradient, HLINEAR );

[GOB52]

@tobozo

Why do you want to include this in LovyanGFX instead of another library that LovyanGFX requires?

[tobozo]

Why do you want to include this in LovyanGFX instead of another library that LovyanGFX requires?

The idea came instinctively because LovyanGFX already has some drawGradient*() and fillSmooth*() functions.

Integrating in LGFXBase is the worst case scenario though, I prefer the idea of src/lgfx_plugins folder where users can eventually contribute/extend their own plugins without affecting the library core.

[tobozo]

@GOB52 here's the class adapter I cam up with, based on your earlier suggestion:

    #define LGFX_INLINE_T template <typename C> inline

    class GradientPluginAdapter : public LovyanGFX
    {
      public:
        explicit GradientPluginAdapter(LovyanGFX* gfx) : gfx(gfx) {}
        explicit operator LovyanGFX*() { return gfx; }

        // Draw wide line with single color fill
        LGFX_INLINE_T void drawWideLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick, const C color) {
          wedgeline::draw( gfx, x0, y0, x1, y1, thick, thick, color ); }
        // Draw wide line with gradient fill
        LGFX_INLINE_T void drawWideLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick, const colors_t<C> colors ) {
          wedgeline::drawGradient( gfx, x0, y0, x1, y1, thick, thick, colors ); }
        // Draw smooth line (1px radius)
        LGFX_INLINE_T void drawSmoothLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, const C color ) {
          this->drawWideLine( x0, y0, x1, y1, 0.5f, color ); }
        // Draw wedge line with single color fill
        LGFX_INLINE_T void drawWedgeLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick0, float thick1, const C color) {
          wedgeline::draw( gfx, x0, y0, x1, y1, thick0, thick1, color ); }
        // Draw wedge line with gradient fill
        LGFX_INLINE_T void drawWedgeLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, float thick0, float thick1, const colors_t<C> gradient ) {
          wedgeline::drawGradient( gfx, x0, y0, x1, y1, thick0, thick1, gradient ); }
        // Single-color-fill circle with antialias, 100% redundant with lgfx::fillSmoothCircle(), but kept for TFT_eSPI legacy and benchmark
        LGFX_INLINE_T void drawSpot(int32_t x, int32_t y, float radius, const C color ) {
          wedgeline::draw( gfx, x, y, x, y, radius, radius, color ); }
        // Fill antialiased circle with radial gradient
        LGFX_INLINE_T void drawGradientSpot(int32_t x, int32_t y, float radius, const colors_t<C> gradient ) {
          wedgeline::drawGradient( gfx, x, y, x, y, radius, radius, gradient ); }
        // Draw gradient line (no antialiasing), like gfx->drawGradientLine() but not limited to two colors
        LGFX_INLINE_T void drawGradientLine(int32_t x0, int32_t y0, int32_t x1, int32_t y1, const colors_t<C> gradient ) {
          line::drawGradient( gfx, x0, y0, x1, y1, gradient ); }
        // Draw gradient horizontal line (no antialiasing), like gfx->drawGradientHLine() but not limited to two colors
        LGFX_INLINE_T void drawHGradientLine(int32_t x, int32_t y, uint32_t w, const colors_t<C> gradient ) {
          line::drawGradient( gfx, x, y, x+w, y, gradient ); }
        // Draw gradient vertical line (no antialiasing), like gfx->drawGradientVLine() but not limited to two colors
        LGFX_INLINE_T void drawVGradientLine(int32_t x, int32_t y, uint32_t h, const colors_t<C> gradient ) {
          line::drawGradient( gfx, x, y, x, y+h, gradient ); }
        // Fill rectangular area with lgfx::colors_t gradient
        LGFX_INLINE_T void fillGradientRect(int32_t x, int32_t y, uint32_t w, uint32_t h, const colors_t<C> gradient, fill_style_t style=RADIAL ) {
          rect::fillGradient( gfx, x, y, w, h, gradient, style ); }
        // Fill rectangular area with two-colors gradient
        LGFX_INLINE_T void fillGradientRect(int32_t x, int32_t y, uint32_t w, uint32_t h, const C start, const C end, fill_style_t style=RADIAL ) {
          rect::fillGradient( gfx, x, y, w, h, start, end, style ); }

        protected:
          LovyanGFX* gfx;
    }; // end class PluginAdapter

    #undef LGFX_INLINE_T

[jgauchia]

Thank you! this week I'll try it!

[GOB52]

It would certainly be nice to be able to use functions extended by the user, like MODs in Game.
It would be ideal to be able to write beautiful code without affecting the LovyanGFX.

[tobozo]

write beautiful code without affecting the LovyanGFX.

Yes and contributions like this one can eventually be dispatched as plugins instead of being closed since it doesn't affect LovyanGFX any more.

It would also make sense to add a boilerplate (e.g. lgfx_plugin_example.hpp) as a nudge for contributors.

[edit] removed template to make it chainable

    class MyPlugin : public LovyanGFX
    {
      public:
        explicit MyPlugin(LovyanGFX* gfx) : gfx(gfx) {}
        explicit operator LovyanGFX*() { return gfx; }
        /* LovyanGFX/M5GFX compatible methods */
        /* custom functions */
        protected:
          LovyanGFX* gfx;
    };

[tobozo]

@GOB52 I found something odd with the adapter pattern, some inherited functions are crashing, some are working:

  MyPlugin blah(&tft);
  // plugin function
  blah.myCustomFunction( 0, 0, 40, 50, TFT_GREEN ); // OK, no crash
  // inherited lgfx functions
  blah.drawPixel( 40, 50, TFT_BLUE );               // OK, no crash
  blah.clear();                                     // crash!!
  blah.drawCircle( 10, 20, 30, TFT_WHITE );         // crash!!
  Serial.printf("Width:%d\n", blah.width() );       // crash!!

[GOB52]

Is the inherited function call this->func or this->gfx->func?
I think the mixing of the two LovyanGFX instances, this and this->gfx, is problematic.

[GOB52]

I am not sure why drawPixel is not crashing, but I think clear() and others are called for empty LovyanGFX instances.

MyPlugin's constructor is called by its own inherited constructor and stores arguments, correct?

// blah.clear() means... 
LovyanGFX empty;
 empty.clear()

[tobozo]

Even if an improbable solution is found for the LovyanGFX adapter class, there's another problem on the horizon: LGFX_Sprite needs an adapter too. So I'm giving up with that angle.

Now testing a totally different strategy, a very ugly one:

LGFXBase.hpp

  class LovyanGFX : public
  #ifdef LGFX_FILESYSTEM_SUPPORT_HPP_
      LGFX_FILESYSTEM_Support<
  #endif
       LGFXBase
  #ifdef LGFX_FILESYSTEM_SUPPORT_HPP_
      >
  #endif
  {
    public:

      #if defined LGFX_PLUGIN_LOAD
        #if __has_include(LGFX_PLUGIN_LOAD)
          #include LGFX_PLUGIN_LOAD
        #endif
      #endif

  };

sketch.ino

  #define LGFX_PLUGIN_LOAD "lgfx_plugins/my_lgfx_plugin.hpp"
  #include <LovyanGFX.hpp>

lgfx_plugins/my_lgfx_plugin.hpp

  LGFX_INLINE_T void myCustomFunction( int32_t x, int32_t y, uint32_t w, uint32_t h, T color )
  {
    setClipRect( x, y, w, h );
    // draw stuff
    drawLine( x, y, x+w, y+h, color );
    fillCircle( x+w/2, y+h/2, std::min(w,h)/4, color );
    clearClipRect();
  }

[GOB52]

I have come up with a way to overload the arrow operator!
How about this?

• lgfx_adapter.hpp

namespace lgfx { namespace plugin {

template<typename LGFX> class Adapter
{
  public:
    using lgfx_type = LGFX;

    Adapter() = delete;
    explicit Adapter(LGFX* gfx) : _gfx(gfx)
    {
        assert(gfx != nullptr && "nullptr");
    }
    virtual ~Adapter() {}

    explicit operator LGFX*() { return _gfx; } // Cast
    // Overload arrow operator (direct access to LGFX)  this->drawLine => _gfx->drawLine
    const LGFX* operator->() const noexcept { return _gfx; }
    LGFX* operator->() noexcept { return _gfx; }
    
  protected:
    LGFX* _gfx;
};
}}

• custom.hpp

template<typename LGFX> class MyPlugin : public lgfx::plugin::Adapter<LGFX>
{
  public:
    using lgfx::plugin::Adapter<LGFX>::Adapter; // for constructor
    using lgfx::plugin::Adapter<LGFX>::_gfx;
    
    template<typename T> void myCustomFunction( int32_t x, int32_t y, uint32_t w, uint32_t h, T color )
    {
        _gfx->setClipRect( x, y, w, h );
        _gfx->drawLine( x, y, x+w, y+h, color );
        _gfx->fillCircle( x+w/2, y+h/2, std::min(w,h)/4, color );
        _gfx->clearClipRect();
    }
};

• main.cpp

    MyPlugin<decltype(M5.Display)> blah(&M5.Display);
    LGFX_Sprite spr(&M5.Display);
    spr.createSprite(64,64);
    MyPlugin<decltype(spr)> blahs(&spr);

    M5_LOGI("parent:%p", blahs->getParent());
    Serial.printf("Width:%d\n", blah->width());
    
    M5_LOGI("%p : %p", &M5.Display, (M5GFX*)blah);
    blah->clear(TFT_ORANGE);
    blah->drawPixel( 40, 50, TFT_BLUE );
    blah->drawCircle( 10, 20, 30, TFT_WHITE );
    blah.myCustomFunction( 0, 0, 40, 50, TFT_GREEN );

    delay(5000);
    
    blahs->clear(TFT_BLUE);
    blahs.myCustomFunction( 0, 0, 40, 50, TFT_CYAN );
    blahs->pushSprite(0,0);

[GOB52]

I think it's not a good idea because of the tinkering with the original source and the possibility of unexpected behavior when mixing pre-inclusion of my_plugin.hpp and non-inclusion of my_plugin.hpp.

My method is

• I don't modify the original source.
• has-a" so there are no side effects to the LGFX instance (no inheritance problems)
• The distinction between arrow and dot operators is a bit confusing, but it clarifies the difference between original class functions and calls to my own functions.

"is-a" and "has-a" is similar to the relationship between "Fork" and "Depends" in a library repository.

Also, the maintenance costs associated with the original changes would need to be considered.

I think we need more people's knowledge and opinions.

---

オリジナルのソースをいじることになるし、my_plugin.hppのインクルード前とインクルードしていないものを混在させると予期せぬ動作をする可能性があるので、あまりいいアイデアではないと思う。

私の方式は

• オリジナルソースコードには手を加えない
• "has-a" なので LGFX インスタンスへの副作用はない (継承による問題を引き起こさない)
• 矢印演算子とドット演算子の使い分けがやや分かりづらいが、オリジナルクラス関数と自作関数の呼び出しの違いが明確になる

"is-a" か "has-a" はライブラリリポジトリの Fork と Depends の関係に似ています。

またオリジナル変更に伴うメンテナンスコストも考える必要があるでしょう。

思うにもっと多くの人々の知見や意見が必要な気がします。

@lovyan03 はどう思われますか?

[lovyan03]

I think it is best to avoid the idea of adding methods to the LovyanGFX class itself from another file if possible.
Looking back, I think the LGFX_FILESYSTEM_SUPPORT_HPP_ mechanism was a failure.
The necessary drawing functions can be imported to the LovyanGFX side to some extent, so I would like the implementation to be as simple as possible.

[tobozo]

The necessary drawing functions can be imported to the LovyanGFX side to some extent

okay I'll try this on a separate branch and submit a pull request for review

[tobozo]

here's my attempt a importing the features in LovyanGFX:

branch: thicklines (view diff)

I'm not completely sure about mapGradient() though, at first I was tempted to put it with colortypes.hpp but now I'm having second thoughts about putting it in LGFXBase.

[GOB52]

BTW, I am going to publish my adapter in my own repository as I think it will be useful and not limited to LovyanGFX.

---

ところで、私のアダプターはLovyanGFXに限ったものではなく有用だと思われるので、自分のリポジトリで公開しようと思っています。

[tobozo]

@jgauchia wide line support has been integrated in the develop branch, thanks again for suggesting this 👍

[jgauchia]

Thank you!