This a better explanation 8bit_single_buffer and 8bit_double_buffer | PicoDVI Arduino Library: Video Out for RP2040 Boards | Adafruit Learning System
You will still get screen tearing between the old frame and the new frame when you do your switch. What your solution here will prevent partially updated frames from being sent to the LCD. This is not the same as screen tearing but very closely related.
The LCD is not wired to allow us to stop tearing. Also, it works completely differently from other display systems.
The LCD has frame memory and this should be your second frame in a double buffer scenario. You do not need to update the LCD frame memory n times a second from the Pico RAM. These are uncontrolled updates from your application’s point of view.
To efficiently “double buffer”, only update the LCD frame memory when you would perform swapping frames in the double buffer technique. This will minimise screen tearing, stop partial updates, and save Pico RAM.
That DVI implementation is a different display system and does not apply to the PicoCalc.
The difference is that PicoDVI is driving the output for the DVI port to the monitor from the information stored in the Pico’s RAM.
On the PicoCalc, the pixels on the LCD screen are driven by the frame memory in the display controller driving the LCD, not from the RAM in the Pico. Modifying the frame in the Pico’s RAM will not affect the LCD until you transfer its contents to the frame buffer in the LCD display controller.
There is no tearing between the old frame and the new frame. And you’re correct, it does prevent partially updated frames from being sent to the display.
Maybe the correct term I’m referring to is screen flickering. But I can assure it has made a major difference. It’s also used in the TFT_eSPI library and from what I’ve seen is a standard to avoid flickering.
Maybe you could provide an example of your implementation (using the C SDK is fine) of what you’re referring to and how it can replace the double buffering that I’m using.
There is tearing but you do not notice it since the old frame and the new frame are close in content. The flickering is caused by partially updated frames sent to the LCD display controller’s frame memory.
The display controller can tell us when it is safe to update frame memory through vertical and horizontal blanking signals, but these are not connected.
Screen tearing is caused when you update the frame memory when the display controller is in the middle of updating the LCD panel. To prevent tearing, we need to update the frame memory when the display controller is not updating the LCD panel. Unfortunately, we do not know when panel is in the update process without the blanking signals, so we cannot stop screen tearing.
Your desire to “double buffer” is correct. Look at it this way. The display controller is doing the heavy lifting of displaying the pixels stored in the frame buffer onto the LCD panel. We do not have to worry about that. Instead of attempting to emulate a CRT monitor, all you need to do is update the frame memory on the display controller when you want to show a new frame, not 30 (or n) times a second. The display controller will display what is in the frame memory forever, hours upon hours, without updates from the Pico.
Pico RAM contains the working frame. The display controller’s frame memory contains the active frame. Update the active frame with the working frame when the working frame is complete.
2 Likes
Beautiful explanation, thank you. That actually makes a lot of sense and would save a ton of ram too. It also cleared up some misconceptions I had. I’ll look into that after I release the Micropython version of Picoware.
I think I’m doing a similar approach in MicroPython actually (I ditched my implementation of double buffering in this version since they have a Framebuffer class that seems to work how you explained)
2 Likes
Great progress today! All of the GUI classes are done and well optimized.
Now I’m working on the System classes. A release tomorrow seems likely at this rate.
Well that didn’t take as long as I thought.
I created an Input class
A View and ViewManager class
I added a loading application
and updated the main script
Now it’s functioning similarly as the other Picoware versions. I just need to add in our “root” applications (Desktop, Library, etc) and then we’re all set.
1 Like
Do you think an hardware mod could allow this?
1 Like
Technically yes - the TE signal on the LCD connector provides that information.
Practically, no - you’d have to get a single wire onto pin 34 of the FFC connector, and that’s a painful job even with a microscope and the right skills. I’ve done it occasionally, I wouldn’t recommend it to anyone who wasn’t already fully aware of what was involved.
2 Likes
@Ben It just isn’t worth the effort. The display is running at 60 Hz and most of the time you will not notice it.
1 Like
My soldering skills are definitely not going to be up to the job…
The release is delayed a little but everything is running well!! Over 220k byes free with the Pico 2W. Now I’m in the final stages (freezing Picoware modules and cleaning up memory). We need about 25k more byes free in order for this to run smoothly on the Pico/Pico W.
Well I got the Pico/Pico W to run now but it freezes when running the view manager (I think because we need a little bit more RAM). I’ll brainstorm some ideas tomorrow and get the release together
1 Like
Maybe it’s worth adding in PSRAM now like in the SDK version
I see there’s already a pio library for MicroPython and if that didn’t work, I can compile the C library and use the APIs directly.
After some optimizations tomorrow, I’ll look into it for sure since that will give us more memory to play with
Well I did create a psram class but I ended up switching to one 8-bit buffer and creating a native module for lcd functions.
The micropython release is set for tomorrow! The views are extremely quick (just as fast, if not faster, than the SDK version). I’ll spend the next few hours cleaning up code.
122k bytes free now on the Pico/Pico W and blazing fast GUI updates. I’m excited for tomorrow’s release
4 Likes
Great day!! Version 1.4 (MicroPython support) is HERE:
2 Likes
I released a tutorial video about using micropython and Picoware:
3 Likes
I worked on a few updates since yesterday’s release:
Screensavers (menu + Spiro example)
WiFi menu (connect, scan, and edit network credentials)
Better exception handling in storage classes
and an on-screen keyboard class
All of those were translated from the SDK version.
Now I’m working on the SD card app loading functionality and a python script editor (the one Zenodante used is from here and is pretty straightforward actually)
3 Likes