Open ropg opened 3 years ago
hey @ropg thanks for your feedback
LovyanGFX will soon become the official core for all M5Stack products, while this is very good news I can only hope it will not drop support for non-M5Stack products such as Odroid-Go or TWatch.
Please note I'm assuming Core2Ez is taking the same direction as M5Stack towards LovyanGFX adoption while writing this answer.
pushInSprite
+ setRotation
-> pushRotateZoom
color16To8
/ color8to16
-> conversion should be native provided setColorDepth() was used
fontsLoaded
-> loadFont( [font] )
returns a bool
textWidth(text, font)
-> use separately 'setFont() + 'textWidth()'
decodeUTF8(buf, index, remaining)
-> not implemented in LGFX (drawChar()
is unicode safe)
error: no matching function for call to 'min(int, std::vector<line_t>::size_type)'
-> LGFX uses its own fast version of min
/max
and #undef'
s them afterwards.
Your library being affected by this means you probably need to do the same.
Some thoughts:
I use egrep -R
+ keywords to find the interesting functions in the LGFX library
I'm not sure TFT_eSPI allows that, but this works with LGFX and may save you from maintaining DisplayZone::push()
and DisplayZone::spriteToDisplay()
TFT_eSprite spriteToDisplay = new TFT_eSprite( &M5.Lcd );
TFT_eSprite spriteToSprite = new TFT_eSprite( &spriteToDisplay );
pushRotateZoom
is your swiss-army knife, this function is fast and powerfulspriteToSprite->pushRotateZoom(&spriteToDisplay, x, y, angle, zoomX, zoomY);
spriteToDisplay->pushRotateZoom(&tft, tft.width() >> 1, tft.height() >> 1, 0, 1, 1);
Wow, thanks...
I've learned a lot about documentation lately, to be used as Core2ez gets proper documentation. I have a setup that uses doxygen and sphinx/breathe that I have tuned so that both the doxygen and the more textual sphinx/breathe output can be referred to. LovyanGFX becomes easier to parse if you look at the doxygen graphs that show object relations and all... I have forked LovyanGFX and am setting it up in the 'documentation' fork.
What are your plans wrt the Chimera given M5Stack's adoption of LovyanGFX?
(They need to take the button stuff back out and only use my touch driver, this is silly the way it is now...)
I've been playing a lot with LGFX library, if I can be of any help to your documentation effort don't hesitate.
I've only scratched the surface of Doxygen with travis, do you know if this could be used in a github action ? Looks like there is an implementation so maybe the doc generation and publication can be automated and triggered whenever a new release is produced.
I know M5Stack is planning to use LGFX code in some unified core but the MCU scope is still unknown. There's already support for ESP32/SAMD, who knows what's next ? (e.g. ESP32-C3'RISCV)
The problems that will need to be solved in order to achieve this unification will probably deal with touch/notouch + button/nobutton conflicts too, so these upcoming change are likely to break some eggs.
Whatever happens, ESP32-Chimera-Core will stick to M5Stack API.
So reporting Core2Ez integration problems here is totally in the scope of that project.
The only concern I have is for the M5Stack-SD-Updater library which has a wider scope since it should work (but never achieved complete coverage) with native TFT_eSPI, old M5Core, M5Core2, LGFX, Chimera-Core.
Check out core2ez.m5ez.com, it redirects to Read The Docs, who do all the documentation building. It's more sample documentation than real right now past chapter 2, but have a look.
Have a look at lovyan03/LovyanGFX#105
Hello. @ropg
LovyanGFX is currently being tweaked to be officially adopted into M5Stack. This includes tweaking it to be more compatible with TFT_eSPI. Some unacceptable specs will be lost, but we will try to add as many as possible that can be provided as functions so that the same ones can be used.
In addition, LovyanGFX v1.0.0, which has a new foundation design, is under development. Therefore, it is not recommended to make modifications in accordance with the currently released v0.3.9.
I'm currently in discussions with M5Stack, and there are several possibilities, including adopting LovyanGFX as it is as an official M5Stack library, or creating a new M5Display library derived from LovyanGFX.
At the very least, the current situation where each product has its own implementation of different display drivers seems to be a problem within M5Stack.
OK, I will wait to do anything drastic and just play around a bit.
Does this also mean we should hold off on documenting? Or is the 'develop' branch much closer to what will become 1.0.0 and should we just start documenting it?
I think we should use our time now to experiment with different ways of documenting things so we know which direction we want to move in.
I think it is advisable to postpone the documentation for now. The base of LovyanGFX v1.0.0 will be completed soon, but due to the many specification changes involved, the release will be phased in. At least in v0.4.0, users will be able to choose between v0.4.0 and v1.0.0 by using the define flag.
Sure.
Can you explain briefly about the differences between what's there now and 1.0.0 ?
It's time to move the discussion to a new location, since it's no longer relevant to the topic of Chimera Core. thanks.
Hey there...
I was trying to see if things "just work" and am having some issues...
I took my Core2ez library and replaced occurrences of
M5Core.h
withESP32-Chimera-Core.h
. That gave compile errrors, mostly about missing methods in TFT_eSprite, which seemed like they want to be replaced by replaced byLGFX_Sprite
. But that is still not working, and then I gave up until I understand better what this LovyanGFX does and how it differs from the TFT driver in the default M5Core2 library. Regrettably, I do not read Japanese...I included all error messages below...