I honestly didn't expect my little project to be accepted into the Arduino Library Manager index on my first try, but it was. Now that it is part of the ecosystem, I feel obligated to record my mental to-do list in a format that others can reference. This lets people know that I'm aware of these shortcomings and see the direction I've planned to take. And if I'm lucky, maybe someone will tackle them before I do and give me a pull request. But I can't realistically expect that, so putting them down on record would at least give me something to point to. "Yes, it's on the to-do list." So I wrote down the known problems in the issues section of the project.

First and foremost problem is that I don't know if PAL code still works. I intended to preserve all the PAL functionality when I extracted the ESP_8_BIT code, but I don't know if I successfully preserved it all. I only have a NTSC TV so I couldn't check. And even if someone tells me PAL is broken, I wouldn't be able to do anything about it. I'm not dedicated enough to go out and buy a PAL TV just for testing. [bootrino] helpfully tells me there are TV that understand both standards, which I didn't know. I'm not dedicated enough to go out and get one of those TV for the task, but at least I know to keep an eye open for such things. This one really is waiting for someone to test and, if there are problems, submit a pull request.

The other problems I know I can handle. In fact, I had a draft of the next item: give the option to use caller-allocated frame buffer instead of always allocating our own. I had this in the code at one point, but it was poorly tested and I didn't use it in any of the example sketches. The Arduino API Style Guide suggests trimming such extraneous options in the interest of keeping the API surface area simple, so I did that for version 1.0.0. I can revisit it if demand comes back in the future.

One thing I left behind in ESP_8_BIT and want to revive is a performance metric of some sort. For smooth display the developer must perform all drawing work between frames. The waitForFrame() API exists so drawing can start as soon as one frame ends, but right now there's no way to know how much room was left before next frame begins. This will be useful as people start to probe the limits.

After performance metrics are online, that data can be used to inform the next phase: performance optimizations. The only performance override I've done over the default Adafruit GFX library was fillScreen() since all the examples call that immediately after waitForFrame() to clear the buffer. There are many more candidates to override, but we won't know how much benefit they give unless we have performance metrics online.

The final item on this initial list of issues is support for double- or triple-buffering. I don't know if I'll ever get to it, but I wrote it down because it's such a common thing to want in a graphics stack. This is a rather advanced usage and it consumes a lot of memory. At 61KB per buffer, the ESP32 can't really afford many of them. At the very least this needs to come after the implementation of user-allocated buffers, because it's going to be a game of Tetris to find enough memory in between developer code to create all these buffers and they know best how they want to structure their application.

I thought I had covered all the bases and was feeling pretty good about things... but I had a blind spot that Emily Velasco spotted immediately.