Hi it would be really good if there was some sort of double buffer or frame buffer control.
Such as update all the elements and then update the frame on the screen.
If you have several animating elements that are layered over each other, without some sort of buffering the layers clip and appear to flicker as each layer is drawn.
Having a control were the layers are drawn and then the screen is updated would fix the flickering.
If there is a frame buffer control that i've missed. Please let me know.
But this would be a good and important feature to have.
You may want to consider issuing ref_stop and ref_star to see if this resolves some of your issue.
Knowing which device you are having issue with will help in providing you with a proper explanation.
Generally there is no double buffer or frame buffer control as the Nextion lacks such SRAM resources.
In the lower MCUs as the STM32F030C8T6, there is 8K that is shared between firmware and user HMI.
In the upper MCUs as the GD32F103RBT6, there actually is 20K being shared firmware and user HMI.
Pixel data on the Nextion uses 2 bytes per pixel in 565 color format when stored in Flash as resource.
Pixel data inside the TFT screen GRAM is 18-bit using 666 color format.
You begin to see the issue for why there is no double buffer when you realize GRAM to SRAM ratio
- 2.4"-2.8" has 172,800 bytes of GRAM while the 5.0-9.0" has 864000 bytes of GRAM.
As the Nextion device lacks the SRAM to implement a double buffer, it makes less sense to implement it inside the Nextion Editor Debug Simulator - this would give the false sense to the user that all is fine with their HMI design while their device would not reflect the same result.
However, the TFT controller (in general, and not necessarily possible for all Nextion models) can sometimes electrically maintain current pixel colors while GRAM is being updated (the appearance of having two values for the same pixel - one in GRAM and the other what is visible on the screen)
This can be attempted by issuing a ref_stop which stops GRAM writes to auto-update the TFT screen, and then issuing a ref_star which then resumes the GRAM auto-updates. The command ref 0 can be issued to ensure the current page is refreshed and up to date.
Unnecessarily overlapping components in your design knowing the flicker result is not amongst best practices and should attempt to be avoided.
In some cases, using image cropping for the 2 components that are overlapped while using a page image background will not produce the flicker. Example: Text within the boundaries of a Gauge component.
Not exactly frame buffer control, but it is the closest you will realize given the limited nature of the MCU
Thanks Patrick its pretty late here now, So ill try it in the morning.
For the record,
I believe that the 4.3" model with the RGB buffer chip might be the only model where this might even be possible. The RGB buffer was selected to work for the 800x480 screens and included with the 4.3" which only has a 480x272 resolution. Hardware wise, the RGB buffer could actually be partitioned into two pages and still have a bit of resources remaining.
The 5.0" to 9.0" device would be unable to do the same, and the 2.4" to 3.5" lack this RGB buffer chip.
There are two versions of the firmware, one for the basic series, the other for the enhanced series.
But we can understand why the firmware is created to be uniform across the whole series.
Sadly that didnt work, ok well. Will have to put up with the clipping. Thanks anyway
Now it's Clipping? You mentioned flickering before.
If the clipping is the result of a font width not being a 1/2 height ratio, of from generating the font inside the Nextion Editor .. yeah. If it is because of the Marquee scrolling text component, perhaps avoid it - I am almost certainly the marquee component was experimental.
Perhaps a different approach on layering. If you post your HMI file, I will take a look and see what can be specifically suggested.
Is the clipping a Nextion Editor generated font issue? - THAT does output cropped characters..
Perhaps if you upload your hmi file, I could take a look for you and suggest an approach.
Sorry i meant the same thing as flickering...
Clipping is when layers intersect. its a 3d terminology...
Though what happens in this case is the object being updated is automatically sent to the front layer.
What i have going on is some image sequences gauges, with a number readout in a part of them. As the image updates to a new gauge position that layer is brought forward in front of the number. Next the number is updated and that beings it forward. This causes the flicker. It would be nice if there was at least a way to fix the layers but i think i already know why that wont be possible, The way the display draws pixels by object update rather than a full screen refresh per frame. Which is also why theres no frame buffering.
Okay I am running blind (I don't know which model or your design yet - hard to be specific) so hit and miss.
The size of "gauge" picture being swapped in and out is going to have an effect on the outcome. If I have a huge picture and 21 picture steps (0 to 100 by 5s), and then every gauge adjustment swaps out the old picture for the new ... the larger the picture the more flicker (assume the cause is the redraw, a smaller picture is not going take as long, less effect). So the objective isn't to redraw the whole gauge each time, but to redraw as little as possible.
For this you would want to put as much of the screen picture into the page background. Be careful, I didn't say create a Picture component as a background with layering by "Bring Top" or "Bring Bottom" arrows. In the Page component change the .sta attribute to "image" and the .pic attribute to a full screen size picture. This frees up a lot of "double" resource refreshing over the picture component sized as full screen (refresh page component pixel matrix -> refresh picture component pixel matrix -> refresh gauge and refresh number). It would only need to refresh gauge and number component.
It would be important in the gauge component to set .sta to "crop image" and .pic to same picture number as used in page .pic attribute.
Minimize the time needed to the update number by making the width and height of the number component as small as needed. If you have a 3 digit number using a 80x160 character size, you can expect more issues, but set your number component height .h attribute to 160 and turn off .isbr attribute to false, turn of vertical centering by setting .ycen attribute to Up If you can, make your number component to only what is needed. In the 80x160 example, 3 digits of 80 width is number component .w attribute of 240. Avoid .xcen of Center, aim for .xcen to Left if possible, or next best .xcen of Right. Where possible do not use .spax or .spay -- they should be 0 where possible. Number component .sta of solid color can out perform the lookups for image or crop image.
Going through the same steps on smaller fonts sized numbers will increase the performance.
Limit your use of pictures where fonts could be used. Ditch any notions of anti-aliasing or font smoothing and get a font editor to fix the out-of-wack pixels.
Try an avoid overlap at all cost.
In this design, the background is a page image and the only overlap is a small "26" number component at the bottom of a gauge component. It runs smooth. This is only one technique, others use cropped image sliders to allow the background to bleed through or be omitted as needed.
Heres a slightly older vid, but you can see the two graphic gauges. Theyre 21 images, 21 gauge needle positions.
my project page
I also have an alternative design idea for the gauges which would eliminate the flashy/clipping issue and save a huge amount of storage by using a progress bar to change between two images.
One thing I would do if under my project would be
- to change the upper number to 2 digit right aligned so the digits landed in the same spot each time.
- a digital 7 segment number would be better than a bouncing centered number.
In a spirit of fun, the fuel gauge and voltage shouldn't jump like that - like what - mystery man adds fuel while at 70 MPH? For an actual application of the two digital gauges, they would be rarely updated and thus next to no flickering to be had. Store current_fuel and current_volts, only update when not the same.
Here the flicker is caused by unrealistic conditions.
Good job on the project though.
Oh yeah, I agree in this case the gauges only update every so often. Maybe every 5 or 10 seconds. The only time the flicker is more noticed is during the startup run up run down demo...
Some things will change as i develop the software and prototype board more. Its an evolving project.
If they are bouncing too much, perhaps an averaging routine. As the float may bounce in the tank, perhaps averaging the last 16 samples may reveal a less bouncy reading.
This would give a new reading every eight samples but maintain an average over sixteen samples.
I am hoping I didn't make a mistake there, but you get the idea.