Start a new topic

Transparent pictures

 Is it possible for you to implement png pictures import without background? This will be very useful for round or rounded buttons.

13 people like this idea

Here's the demo.

But the function is not perfect yet, affect the refresh rate a lot.

It's suspended for we have more important things to do. 

utf-8 support is top priority at current stage.


3 people like this

I agree it's more important now for you to add extended ascii support.

But I have a suggestion for you. If you enable transparency only in compiler. This means that user adds png picture on the screen you compile with the current picture background or maybe selected picture background. This will be much easier for you. I know it's not perfect but while you are developing useful transparency this will help us. In 95% of buttons I have rounded edges or round buttons and I have to manually position and crop it and then I reposition in Nextion sw. Example with cropped button (button) below:

(9.87 KB)
(11.8 KB)
(107 KB)

2 people like this

If I might suggest, transparency handling is VERY important. I've managed to use the crop image to hide ugly sliders with a page of static imagery (though of course this makes the size go up dramatically every time you add another full screen image - NOT the answer) - but for on-off buttons - I just cannot find a way to implement some of the VERY pretty round lit up buttons as these need transparency.

Please implement this as soon as possible.

Also - your 4-byte number format for returning data - I can see the use for it but a switch to offer ASCII numbers would make sense.   You can ACCEPT an ASCII string like "T0.val=45" - but that's not what you send back out. I've had to jump through hoops with Node-JS to get the information back into a simple format.

3 people like this
I'm also in need of support for PNG, but not just for non-square shapes (round buttons, etc) but also for support of opacity in the rest of the image.


2 people like this
Here! here! for Transparent button handling!... Much needed.  Please add me to the list of needy people!
Buttons look ugly! Transparency looks like black corners!


2 people like this
I don't think you will be added to "needy people" list :)

But transparent buttons aren't supported yet but what you can do is to crop round button on the same background you will use. So button looks rounded but it's actually rectangle and because of the same color you wont see those ugly edges.


1 person likes this

I think it would be sufficient to define one color as transparent color for each picture. So you can use a color that is not used on the screen. The picture drawing routine replaces pixels with this color with the pixel of the backgroud image.   

@Soeren, though this topic was started Aug 2015

In the Basic Nextion Model Series you have but 64K of flash and 8K of SRAM (less the firmware).  The TFT screen's GRAM is between 172800 bytes on the 2.4", and 864000 on the 7" models.  Remembering that that 8K is split between the firmware and the HMI project you are designing.  Your graphics is certainly not in this limited 8K of memory.

So clock cycle time, on a 5"/7" display you have added an additional ~1.5 million branch instructions. (plus other address, compare, data instructions) and lessened the available HMI SRAM from 3584 to now even less, as your added firmware routine chews further into the already limited available SRAM.  This will allow you to do even less intelligent (talk to other sensors, make calculations) in your HMI.

Ever wonder why the desktop offloads such graphic computations to a faster than CPU graphics card?

Perhaps, with a few MB of RAM, you could have your host MCU or Arduino keep track of the various layers (it really boils down to windowing verses flat) and send it over to your display.  Because once you have chewed up that limited amount on the Nextion with local display side functions and routines, I am less certain there is enough left over to load and run your projects HMI design.

Food for thought.

Hi Patrick,

I think  ITEAD will concentrate on the Enhanced series in the future. The price difference between the 7.0" basic and the 7,0" enhanced Display is 7 USD. So I would always select the enhanced display.

To my Background: I started programming in 1983 on a Commodore C64 in Basic and Assembler. The next machine was an Atari ST. These homecomputer CPU were less powerfull than actual PCs but there have special helper ICs for the graphics, f.e. the Blitter in the Atari ST for fast Logical operations in the graphic memory.

I amnot sure wich possibilites the Display Controller on the Nextion have. The xstr command can print a text on a background Picture, so there must be a concept of transparent pixels.

In the old Homecomputer days we used a black/white mask image in addition to the real image to define the non-transparent pixels. When using Buttons of the same size you need the mask image only once.

Implementing an Alpha channel will indeed an overkill for the Nextion MCU. 

 maybe it is too easy just to design all as graphic? And for the ones who care about filesize, one full-screen graphic can contain many different objects without increasing its size ...



1 person likes this


Yeah, those were the good ol' days.  I too was weaned on the less capable: The DEC VT52 (okay it connected to a VAX I never saw), to the CoCo4, to the Ti-99, to the TRS-80 (pronounced trash-80), to the Commodore Pet before the C64.  I went to the Intel PCs over the Motorola 68s.  Yeah, I get it.  But then, we should know better to conserve those very few and scarce resources. 

The Enhanced series, abandons its 48MHz in favour of a 72MHz and 100MHz, but SRAM doesn't jump exponentially.  It too is relatively scarce in resources but extends some of the GPIO out so users can be further challenged to manage the little there is.  =)

As for the helper IC, the Nextion's STM MCU has access to the ILI display driver (chip embedded in the TFT) for addressing the TFTs embedded GRAM, the touch sensor has a helper chip to translate touch before getting to the MCU and outside of that, it is my belief that the MCU is responsible for emulating all the remaining ROMs and helper ICs the old home computers had.

You are right in that there is a subroutine function that does a value compare between the pixel being rendered and the existing value in GRAM, and it is definitely made use of in rendering the mono-bit font and in the crop-image routines.  But, we have access via the Nextion Instruction Set, and not the MCU assembly. 


Is there a documentation which ILI Display Driver chip is used for the Nextion HMI Displays?


No direct black and white documentation, I am making a straight assumption from the lack of other hardware and other suggestive clues - not to be 100% gospel it is an ILI.  The type of screen used in the 2.4"/2.8" etc operates in the same general principle - there is an embedded IC in the TFT itself, usually an 8080 or a compatible using a compatible 8080 instruction set.  It could be an Epson or other, but we do know it is either 16 or 18 bits per pixel using the 565 format from out HMI color selectors .. and the 565 format actually suggests it is a 18-bit display using a 16-bit word value as input, as most 16-bit displays use the 555 format.  So 555 is actually only 32768 colors, and we are told in the specs it is 65536.  Not 100% certain, and it is not uncommon for 18-bit displays on the market (262,144 colors) to state 65536 if they are limited to the 565 16-bit input.  Also, if it was a 16-bit 555, I am sure they would have set the 16th bit as a transparency bit, and this conversation wouldn't be occurring.

Transparency handling is a MUST to give the graphic designers the freedom to give their designs the look THEY want!!! Not only for buttons, but also for other components. For example if he likes to use gauges like the attached examples, it's possible with 3 layers: background layer with the scale, the standard gauge layer and a top layer with a transparant window to the gauge and background layers. If the display with his controller is pixel oriented, you can make the choise to write or to not write a pixel depending of the color of that pixel. The comparation with destops is is not applicable, we want no 3D, no rotations/translations, only drop an image. Maybe somebody (firmware designer) can explane how this works on the Nextion displays?


(470 KB)
(98.3 KB)

2 people like this
Login or Signup to post a comment