We're Hiring a Project Maintainer and an OpenGL Expert! 🚀

[kisvegabor]

Hey Guys,

I’m excited to share that we are extending our team with these two new positions. Of course, in both cases it’s a huge plus, if you are already an LVGL contributor.

Project Maintainer
As a Project Maintainer, you will play a crucial role in steering the direction of the LVGL library. Your responsibilities will include managing the project’s roadmap, overseeing contributions, and ensuring the library remains cutting-edge and user-friendly. If you have a strong background in software project management, a passion for open-source projects, and excellent communication skills, we want to hear from you! Learn more here.

OpenGL Expert
We are also seeking an OpenGL Expert to enrich our team’s expertise in advanced graphics rendering techniques. This role involves optimizing LVGL’s use of OpenGL for enhanced performance and capabilities, developing new features, and contributing to the library’s evolution. If you have deep knowledge of OpenGL, experience in embedded systems, and a desire to push the boundaries of what’s possible in embedded graphics, let’s connect. Learn more here.

Joining LVGL means becoming part of a dynamic, supportive community dedicated to making high-quality embedded graphics accessible to everyone. We offer a collaborative environment where your work will have a direct impact on millions of devices worldwide.

If you are ready to take on exciting challenges and contribute to the future of embedded graphics, check out the detailed job descriptions and apply through the links provided. We’re excited to welcome new talents to our team and together, continue shaping the future of embedded graphics!

I’m looking forward to hear from you!

Cheers,
Gabor

[tdjastrzebski]

It sounds like a new LVGL direction

[kisvegabor]

Well, LVGL is getting larger, more and more partners are coming with custom needs and we need to scale up a a little bit.

[tdjastrzebski]

It will be interesting to see how this develops. After all, unlike e.g. QML/Qt, OpenGL was not meant to define user input behavior but ofc I am sure you know that.

[kisvegabor]

We are planning to use OpenGL to render the widgets with it by utilizing the video card. There is a big company who is interested in it, and now we need an expert for that

[kdschlosser]

Why OpenGL and not using direct hardware API’s. After all there are only really 3 major video card vendors these days. Nvidia, ATI (AMD) and Intel. This is a rather strange thing to do. While I do understand why someone would want to use OpenGL the reality is that OpenGL is made to provide a common API across many video cards. The issue there is there is the API is only going to support the the features that are common across the adapters. So anything that an adapter might have in terms of advanced rendering techniques will not be benefited from.

OpenGL is also not going to be written in a manner that makes it efficient in both program size and also resource use. This is the single driving thing behind LVGL. It is the reason why LVGL was created in the first place.

I know that it would be easier form a maintenance standpoint to only code the single renderer but you will loose too much in doing that.

It’s kind of like selling your sole for an easier path to get to heaven. LOL.

[luka177]

Well that is really strange point. 1st of all it not “just” 3 its OMG 3. 2nd its for sure not 3, you forgot qcom adreno, powervr and arm mali both of those are common to find on embedded system and there is apple silicon, didn’t see that used on embedded devices tho. And then should i remind how much time was spent to write drivers for them that would provide OpenGL, and even to this date there are some GPUs that have no oss driver.

[kdschlosser]

It looks like specific drivers would have to be written for adreno, powervr and arm mali because they have their own way of dealing with openGL. It doesn’t look like you could use a single opengGL SDK and have it support everything that is out there. You would still need to write specific drivers for each of those. So why not just bypass the whole openGL aspect and go directly to the hardware API to do the same thing.

[luka177]

OpenGL is cross-platform, may be what you refer to is lack of OpenGL in downstream drivers doe mali, adreno and powervr. They only support openGL ES, but that is easy to resolv on mai and adreno by using mesa as your driver, on adreno you can even use mesa userspace with downstream kernel driver. And OpenGL is same on all platform as long as platform fully support version of OpenGL you use.

[kisvegabor]

Hi @luka177,

Aren’t you interested in a contractor work with OpenGL?

[luka177]

Hi!
I would be, but sadly i doubt my level of knowledge in hardware rendering and OpenGL in common is deep enough for such complicated but interesting project.
Anyway sorry for flooding this thread if that was a concern.

[kisvegabor]

I imagine it as caching software rendered bitmaps to textures and making OpenGL blend those textures. Once we touch this topic we can also add some drivers to make the whole software or OpenGL rendered UI pushed into a texture. This way we could use normal OpenGL things in an other texture(s) and LVGL together.

@luka177

Anyway sorry for flooding this thread if that was a concern.

Not at all! Having great conversions is always good. I was asking because it’s clearly that you have a great understanding of the topic.

[mvladic]

@kisvegabor

I imagine it as caching software rendered bitmaps to textures and making OpenGL blend those textures. Once we touch this topic we can also add some drivers to make the whole software or OpenGL rendered UI pushed into a texture. This way we could use normal OpenGL things in an other texture(s) and LVGL together.

Hint: Maybe you can take a look at Dear ImGui. This project supports various rendering backends and one of them is OpenGL. For example, it uses imstb_rectpack.h for e.g. packing rectangular textures into an atlas. I think, similar to LVGL, it also has a list of drawing commands which are then rendered by the backend.

[kisvegabor]

Hi Guys,

I’m happy to share that Liam Howatt joined as a project maintainer.

[FishOfTheNorthStar]

Hi, I wanted to volunteer to help test any emerging OpenGL features and perhaps develop some demos.

I have a lot of experience with Godot, Unity (and from that, custom shaders), and I’ve made a small tank/helicopter game for the Raspberry Pi utilizing flat panels rendered in OpenGLES (arm mali I believe), which sounds like the direction you’re going here with LVGL. I’ve also developed some OBS shader-based transitions that use composited flat-panels as well. A concept I’m working on here on these forums involves remapping one or more textures onto a render-baked 3d image that has extra information embedded like normals, UV tex, and approx lighting. This is also what I did with the OBS transitions, but animated, so it could display one video source projected onto a 3d rendered shape (screen exploding), and reveal another video source below.

I am also seeking employment in this industry, but to be completely honest I just don’t think I’m skilled enough to deliver the work product you need, in regards to bare-metal coding, driver development, etc. Maybe I could be, someday, but for now I push rocks up a hill for my dayjob and work on MC / graphics / gamedev projects on the side.

So I’d like to just get involved in some way contributing if I can, and in the future who knows. I’m sure I could implement even basic OpenGL features in interesting and novel ways

[kisvegabor]

Hi @FishOfTheNorthStar,

Thank you for writing! We just opened an OpenGL related Pull Request: feat(widget): Add `lv_3dtexture` widget and 3D draw task type by liamHowatt · Pull Request #8033 · lvgl/lvgl · GitHub

In general we have an OpenGL driver which just caches software rendered content to OpenGL textures and blends them when needed. However here we bypass this cache, and perform simple fills with OpenGL directly.

An amazing update would be to add direct rendering support for more drawings (rounded rectangles, arcs, lines, etc).

We were also thinking about utilizing nanovg.

What do you think?

[FishOfTheNorthStar]

That looks amazing, thanks for the links. I’ll try that out. I haven’t used nanovg but it looks very promising. Nanosvg, too (GitHub - memononen/nanosvg: Simple stupid SVG parser).

Three things I could see a lot of benefit to:

SVG rendering: Many graphics could be made very small compared to their bitmap versions. It seems like Nanosvg can feed SVG data to Nanovg, so that sounds great to me.

Slice-9 panels: These are a 3x3 grid of quads, each getting a different corner/edge/etc from a supplied image. The artist defines the left, right, top and bottom slice edges, which are generally (but not always), set in from the actual image edge by some amount. Then when the grid of quads is created, it’s metrics mirror the corners and edge thicknesses of the specified template, and the edges stretch (or tile) horizontally or vertically. And the central area stretches to fit the specified output size, which can vary per instance. Many interesting and graphically rich UI’s can be made from slice-9 panels (it’s a fairly standard gamedev UI creation system, Godot and Unity and others use it a lot)

Custom OpenGL Panel Shaders: This may be a tough one, but to clarify I’m not looking to be able to define particularly intensive shaders, just a way to specify a number of source textures and a couple user parameters, a vertex shader to attach data to points it then uses in the fragment shader to rasterize the triangles those points define, which would lookup pixels from the specified textures from the interpolated UV of the vertex. It would then use those pixel color channels to form another UV coordinate (and/or vector normal), and with it lookup another color value from another texture, and then output that color to the triangle. So no lighting, or advanced surface qualities. Godot is a lightweight, open source game engine with extensive support for custom 2D panel shaders. Typically I use Blender render-baked images as those textures, but some of them could be made with vector graphics and very specific gradients. This allows for something like SNES Mode7 graphics, and dynamic matcap lighting

Oops, ok… 4 things. I forgot how awesomely lightweight matcap lighting is compared to the quality of it’s output. I think you’d find it a good fit for your 3D needs on embedded platforms. So…

Matcap Lighting: This uses two of the geometry surface normal components to form a UV coord it samples a ‘matcap texture’ with. Matcap textures look a bit like reflective sphere photography, with the sphere going out to the edges of a square canvas. This provides a fairly high quality lighting model that is computationally basically free. Matcap textures can be very small, or created dynamically, to allow the light source to change direction.

Matcap sample (from another thread on these forums):

The “Mode7-ish” effect (this is kdschlosser’s optimized version of my example). I could also see an eyeball motif working out great for round LCDs