Hi,
Couldn’t find any reference if LVGL supports displays with non-square pixels, like physical 16:9 aspect ratio with 800x480 resolution. Something like automatic font scaling, bitmaps and other stuff scaling could also be useful.
Regards,
Vas
2 Likes
Hi,
This feature is not supported, and to be honest I’ve never seen a display with non-square pixels so I don’t much about it 
Are there typical pixel aspect ratios?
I’ve heard that non-square pixels are quite popular in low-priced Android devices, but I just started to scratch the surface of the topic. I’ve bought ESP32-8048S043C (ESP32-8048S043 | macsbug) and am trying to figure out what to do now lol
It looks like non 1:1 PAR is not uncommon List of common resolutions - Wikipedia
Wow, it’s really unexpected. It seems the PAR can be any ratio.
I move this topic to the future request category. If it will interesting for more people we can figure out how to support it.
My LCD is 7 inch, 800 *480 ，but the arc is not normal.Does the LVGL can support for
non-square pixels lcd?
Yes, it seems.
Okay, we got traction on this topic
You must avoid circles, it looks silly.
This display is very popular, because of good price.
1 Like
I have this issue many LCDs have non square pixels
Is there a temporary fix for this?
1 Like
There a re few complicated questions here:
- What to do with the rounded corners: LVGL need to draw ellipses (i.e. distorted circles)
- What to do with the fonts? If LVGL needs to transform them (i.e. +20% horizontal scale) it will be slow and ugly
- What to do with the images? It might be ok to use pre-transformed images.
Pre-transforming images and fonts might need to be done twice, if supporting perpendicular display axis is needed(like 0/180 can be shared, but 90/270 cannot be shared with 0/180).
1 Like
If the Pixel Aspect Ratio(PAR) diverges too far from 1.0, anti-aliasing may need updated. For PAR<1.1, it might be close enough, but when I used a display with PAR=3, we had to fix anti-aliasing it to keep lines smooth.
Wow, it’s getting very complicated. Maybe it’s easier to render all these if a vector graphics GPU available . In this case we can define a constant matrix which distorts all drawing operations.
1 Like
Wow, good to know, thank you!
It seems really difficult to handle to be honest. Especially with good performance.
Hi There,
I just wanted to add that my company buys directly from the fab displays and they are also not always 1:1. I was wandering for a time why the simulator is round and the display is oval…
Pixel Size: 0.1506*0.1432mm
Best regards!
Thank you for sharing. I think we have 2 options:
- Implement a very fast special transformation function that can be called in the flush_cb.
- As it will work on the rendered image it will support all the LVGL shapes
- It will be slower and result in blurred edges
- Add ellipse rendering and use pre-transformed images and fonts
- Its’ fast and good quality
- Requires work on the user’s side to prepare the images and fonts, and set the sizes correctly
- would that special transform function take a lot of RAM?
- That would be over all a very useful feature and doubles as a solution for that problem.
I think both solutions are interesting. The blurring might be a show stopper, depending on the strength. The reason why I think 1. is interesting is that the pc simulation is not equal the real MCU implemtation, which cost a lot of time in the fine tuning phase.
Best Regards!
Not necessarily. Let’s say 100x100 needs to be transformed to 100x120. We can render to the 100x120 buffer initially and leave the last 20 lines blank. After that starting from the last line we can do the transformation. E.g.
y:120 = mix the pixels of y:100 and 99 in a smart way.
Implementing this would be quite simple, so it’s a low hangig fruit that we could try out quickly.