triadapoly.blogg.se

Ivi pro drm
Ivi pro drm









ivi pro drm
  1. #Ivi pro drm code
  2. #Ivi pro drm mac

To be fair, Skia appears to be able to consume either of them, but none was available for my Linux target. MS Direct2D or nVidia’s NV_path_rendering. Unless the stuff is already implemented by some knowledgeable people outside ad.

#Ivi pro drm code

Source code tells opposite story, they’re doing a lot of graphics on CPU. Marketing materials tells how they using GL and Vulkan for performance. I don’t like Skia underneath, too much legacy and overall CPU-centric design. However, this means no library ecosystem, and non-trivial chances to waste lots of time working around bugs in language, compiler and runtime.Ģ. New programming language with Flutter being the only use case. Here’s why I was reluctant to choose Flutter.ġ. Both me and my client were happy with the outcome. NET Core, and implemented a GUI in C#, with animated transitions and such.

ivi pro drm

I picked NanoVG (later on I’ve patched it a bit improving fonts ), compiled a shared library, consumed from. I’ve evaluated Flutter couple years back, chose not to. I did it a few times for various Linuxes using Broadcom and Mali GPUs. It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context. Why would you run a desktop manager on a computer that runs one program only?įor embedded, drm/kms is IMO better level of abstraction to base on. These two things implement desktop managers. That made me add more desired features, etc., but very enjoyable.Įmbedded doesn’t need wayland nor X.org. It was the kind of project where when I had time to work on it, after work, I had a list of things I wanted to do, and I could quickly check off feature after feature instead of fighting the system. My computer ran hot while running Flutter, though not sure how much of that is debug/release mode. It still produced relatively fat binaries, though not sure how much of that was debug/release mode.

ivi pro drm

In particular JSON parsing felt very non-obvious, even though it feels like at this point is should be a first-class feature. Because of the above, interacting with a database / JSON on disk felt a little contrived. I didn't understand Futures very well (and honestly still don't) this might be an issue with people working with modern Python/JavaScript/whatever. The debug view is so so useful for figuring out painting and layout issues. Very easy to add your own painting code if you wanted a custom component.

#Ivi pro drm mac

It was super easy to build for Android, iOS, and Mac all at the same time. I think there's a lot of "this class works with defaults and breaks otherwise" feeling, though the core components are robust enough that this isn't a huge concern. The toolkit feels fairly mature and not too hard to parse. I can give a list of pros/cons that probably overlaps what you've heard: I also, independently, started writing an app in Flutter for fun (no experience in mobile/desktop GUI work, several years since I've worked in front-end web). (I work on KDE Plasma, including its Wayland support, and am a system architect for a large automotive OEM making Wayland-based infotainment systems, neither of which use Weston however.) Due to various factors Weston may be what they already have patches in hand for, e.g. These are blanket statements the devil is very often deep in the details.ĭepending on the OEM you work for and how vertically integrated your organization is, you may also have a large and complex supply chain catering towards your products, with complicated RASIC matrices for who supplies you want and vendors held to KPIs for their BSP and their hardware. It also doesn't have any of the Gnome dependencies. ivi-shell) and partial support for using hardware overlay planes for power-conscious compositing. fallback codepaths for multi-plane buffer formats doing the blend in a shader, support for certain deprecated protocols (e.g. Weston has better support for some things embedded developers care about, e.g.











Ivi pro drm