Unofficial Nextion/TJC User Forum

Project optimization

Hello guys, I`d like to know what is more performance(not flash memory) efficent:

  1. picture with incorporated text that changes to other picture using .pic variable
  2. transparent text on picture that changes to other text using .txt variable
    image

Also is there a way to let`s say ‘benchmark’ and measure such things(irl or debugger)?

Hi and welcome @Cismus!

First a small preliminary note: you don‘t need an extra text component on top of your button; you can write your text directly into the button component and have a picture background at the same time. In the following I‘ll assume that exact scenario.

What‘s faster?

I‘d guess that the images are more efficient since it is a simple, single layer graphic; basically only transfer pixel data from flash to screen. Text on the other hand involves rendering. And if it‘s text on top of a picture, well, the entire text loading and drawing is additional.

Does it matter? How to measure?

Not sure if what I said above matters (assuming my guess was right); never measured it. But unless you have dozens of buttons with frequent updates on the same page, I‘d say no, doesn‘t matter.
Much more important is that even though images might be faster, they‘re a pain in the a** if you ever need to make any change. I know it because I had an entire UI designed with pictures instead of text. Basically any change to the button (button size, font, font size, color, text) requires you to make a new picture, import it into nextion, replace the old one. Think trice about this before you go for that path.

Now for the measurement itself. In case you haven‘t noticed yet, the debugger/simulator runs so much faster than the actual device that it‘s completely unsuitable for any sort of performance measurements. It also very likely works differently under the hood and thus is not only faster but just not comparable timingwise.

If all you want is the difference between both methods, it is rather simple:

printh 01
for(sys0=0;sys0<100;sys0++)
{
  // Press the button
  click button,0
  // Not sure whether doevents is needed for getting meaningful measurements but I‘d say yes. doevents processes all changes and draws a fresh image to the screen.
  doevents
  // Release the button
  click button,1
  doevents
}
printh 02

Run this code for both versions of your button and check with a scope, arduino, etc. how long it takes between the two serial messages. If in both cases you get consistent readings (important!) then the difference between the cases must be the time spent on the additional processing in one of the variants.

This only works because everything else is the same and thus cancels out in the comparison. That also means that you can only state that „variant a is x seconds faster than variant b“ but not „a is x percent faster“, because you‘re not measuring how long each variant takes, but how long each variant plus all the stuff around takes. In a difference that doesn‘t matter but in a quotient it does ((c+a)-(c+b) = (a-b) but (c+a)/(c+b) != a/b, a,b being the times to draw either button, c being the for-loop, the serial processing, etc.).

What would be required to measure a,b directly? Well, ideally you‘d like to have c=0, a.k.a. nothing else running. But that‘s not possible, so you‘d have to determine c. It gets even worse if c is different in either cases. You could f.ex. just run

printh 01
printh 02

Then add the loop. Then the first doevents, then the second, check how the time is scaling with the number of iterations, etc. You could do all this in one step but doing it slice by slice allows you to check each measurement against the others for sanity (f.ex. to catch things like a second doevent being much faster if nothing‘s changed since the previous one; not saying this is the case but you can see how such things could cause false measurements when only removing the two clicks from the example at the top).
This obviously is a deeeep rabbit hole :grinning_face_with_smiling_eyes:

Edit: while Nextion has timers, too, I‘d not use it to make measurements like these because they run on the same system and nobody knows how they interfere with each other (do they update when a loop is running? When doevents is running? Etc). Hence the serial commands to be able to make a measurement with an independent device.
If it‘s a nextion screen with GPIO pins, one could (and likely should) use those instead of the serial.

Kind regards,
Max

1 Like

Wow, first off I`d never expect such extensive response :smiley:

While thinking about literally thousand other things i completly forgot text on component function /facepalm/

In terms of measuring lag im mostly concerned on visual response and as You mentioned, possibly only nextion employees posses this ‘mystical’ knowlegde about how this system actually runs so I woundln`t necessary trust results from serial.
At this moment Im planning to make simple device similar to used in measuring pixel lag of desktop monitors. It would consist of servo(e.g. pressing repeatedly a button), most precise light sensor ill find in lab, mcu with interrupt and some 3d printed chassis. If it works ill make thread with results :wink:

As for the visual lag there’re two things: 1. processing/preparation time and 2. drawing time.
Especially for the lower end, high resolution displays (f.ex. basic series with 800x480 px) the draw time for the entire screen is in the 100s of milliseconds order of magnitude - they just can’t write the data faster to the screen. That means that even 50x100 sized buttons have visible tearing when being redrawn (ofc depends on what you redraw; black on white will obviously be the most noticeable).
In other cases it may be less extreme but it’s still something to keep in mind.

I actually don’t know if this drawing time would be measured with my proposal (a.k.a. is drawing a blocking or non-blocking operation?).
That aside, I can’t see issues with the suggested way. Sure enough, serial is fast. The thing is, it doesn’t need to be fast, it only needs to be repeatable (because then you can profile it as suggested and factor out).
Another advantage is of course that the serial/gpio method works for any sort of profiling on nextion, not only visual stuff.

As for the Nextion guys knowing more, they seem to become a little less secretive about such things recently (which is great and overdue IMO). Sooo there’s a chance that they’ll make a blog post about this in the future.
Til then I’m waiting for your results!

Kind regards,
Max

1 Like

This forum is in no way affiliated with NEXTION®, ITEAD STUDIO®, TJC®, or anyone else really. All product names, logos, and brands are property of their respective owners. All company, product, and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement from the respective rights holder(s).