Add displayio support about adafruit_blinka HOT 15 CLOSED

since we have 'tons of memory' - you can keep 2 framebuffers of the current state, one for what is on the screen right now, and one of what you want to draw on the screen next, and then we can do a numpy-powered comparison to find the dirty rectangle changes.

from adafruit_blinka.

I'm trying to figure out how this would work since it would be implemented in Python. What advantage this would provide over using Adafruit_CircuitPython_RGB_Display? The only thing I'm coming up with is maybe it provides a unified interface for the displays and works with some of the examples. Are you thinking about having it display the Python terminal as well? Also should we wait until displayio development in CP slows down?

from adafruit_blinka.

All good questions. I have no easy answers. Is it expected that CP code that uses displayio will run without modification via blinka magic?

from adafruit_blinka.

I would imagine. Another question though is what if they have a PiTFT with something like FBCP already running on it. Should it try and "take over" the display? Maybe only work if they don't have the PiTFT running? What if they are running it on a Raspberry Pi with an HDMI monitor? Perhaps a virtual LCD? I guess there's lots of design questions. Perhaps this would be a good discussion for "In the weeds" during a CircuitPython meeting.

from adafruit_blinka.

After using PIL on the Raspberry Pi a bunch last week, I think building a displayio module for Blinka that uses PIL under the hood would work awesome. This way we wouldn't need to maintain two different versions of examples and guide pages this way and it would probably cut down on a lot of work. Just a thought. :)

from adafruit_blinka.

yep, we'll get to that - all good.

its a different way of managing screens than pygame/pillow, and there's situations where people want the extra font/image/animation/graphics handling that pillow can provide. architecting it is not trivial and i'm willing to do the maintenence on the epd/rgb displays til then :)

when we're ready, we'll post here and assign!

from adafruit_blinka.

Sounds good. Thanks :)

from adafruit_blinka.

Looks like we're starting to approach a good place to do this (after the HT16K33 updates). I think the first step on this will be to stub it out like Scott suggested on #214 (the bleio issue). Then we can start filling in the blanks. Then we can optimize.

from adafruit_blinka.

Ok, I've put a lot of thought into this issue lately and want to share some of my thoughts:

• displayio should run in the same space as Adafruit_CircuitPython_RGB_Display and be an alternative to that library
• It should be written in Python so it is compatible on many boards
• We are now using ioctl for spi and i2c and that has proven to be fairly quick
• For backlight control, if there's now PWM, we can just round it to the nearest percentage and do on/off
• It may just be too slow to run on certain boards, but right now it doesn't run on any of them. :)
• I'm going to try and avoid using Pillow for now because that just adds another dependency/layer of complication, but it's not ruled out.
• I'll start with a basic ILI9341 and go from there
• Adafruit_CircuitPython_RGB_Display will make a good reference because it makes use of the init codes like displayio does. The main difference is that the displayio drivers each supply the codes.

I'll add more thoughts as I remember them...

from adafruit_blinka.

@tannewt for adding displayio, what are your thoughts on that the actual implementation? For instance, I'm not sure why you took the approach with _bleio as a separate repo. I could either do that or create a displayio.py file here. However, being that it should be pretty agnostic and on the complex side, I'm more inclined to take an approach like _bleio.

from adafruit_blinka.

@makermelissa I would also do a separate repo. You can always depend on Blinka for things you need.

Approach-wise, I think I'd basically re-implement the C code in Python. You could try to actually do it as a native module but I'm not sure if that's an approach worth learning.

The split between display buses and displays you'll want to keep. You'll also want to mimic the dirty rectangle behavior because you'll still be SPI bus speed limited. For the actual pixel computation it's probably better to simply use a Python library to render into a buffer for each dirty rectangle. The pixel computation is the hairiest part of the native code.

from adafruit_blinka.

Thanks @tannewt! The python approach is what I was planning on. A native approach would require reimplmentation for each microprocessor.

from adafruit_blinka.

As @tannewt suggested, I'm going to use a python library to handle the actual drawing. I'll go with Pillow since I'm familiar with it and it works reasonably fast. This will allow me to get something up and running in a reasonable amount of time. We can always rewrite the underlying subsystem in a later version if we feel that would be an improvement. I was originally debating between this approach or using drawing techniques such as in RGB_Display, but am opting for this method so I don't need to worry about writing mirroring or or xy swapping functions at this time.

from adafruit_blinka.

Ok, thanks. :)

from adafruit_blinka.

I'm going to close this since we now have support that works with most TFT situations in https://github.com/adafruit/Adafruit_Blinka_Displayio. The main things that still need to be added are ePaper display support and OLED support, but there's already issues open for those items.

from adafruit_blinka.