Hi Martin, On Thursday, 2016-01-28, 11:45:09, Martin van Es wrote: > Hi Kevin, > > Thx for your insightful reply! Thanks, but I don't really have that much insight myself really :) > On Thu, Jan 28, 2016 at 11:18 AM, Kevin Krammer <krammer@xxxxxxx> wrote: > > So EGL is to OpenGL what Vulkan WSI (window system integration) is to > > Vulkan, > > the connector between the things that are system specific to the things > > that > > are the same across systems. > > For laymen, like me, this is an unpenetrable labyrinth ;) although I try to > catch-up as you can see. Since this whole area isn't something I deal with myself, I also only have a very high level view on things. In a lot of these cases a "new thing" is most often not a replacement for something, but a specialization for a certain group of use cases. E.g. in the case of Vulkan, it mostly targetting developers who provide graphics middleware for application developers, like game engines or like Qt's QtQuick. The "old" technology, in this case OpenGL is still the thing application developers will use when they are not using any of these middlewares. We see these kinds of "new lower level" all over our software stacks, when things that traditionally have been done by every single application developer are now taken care of by dedicated library/framework developers, who can be bothered with more complexity or require deeper understanding but will get better control or more options in return. > > Then my suggestion would be to use that for the time being :) > > True, but my concerns were about being taken over by progress and KDE > developers not being aware their efforts cause harm in "the field" > currently. > > Besides, there is a warning when enabling EGL in Compistor System Settings, > but it only warns about disabling compositor if EGL is not available. I > think a warning about maturity and stability would be appropriate? EGL has been around for quite some time already (more than a decade, EGL 1.0 is from 2003) and has become *the* OpenGL system integration on basically any platform. So it is certainly mature and considered stable (the newest version is about two years old) as a technology, but each vendor's implementation might not or might even change. > > I think it is in Intel's best interest to provide a well working EGL way > > before GLX is being phased out. > > You make it sound like it is the (lack of) maturity of Intel's driver > that's responsible for my experienced plasma's instabilities? I am only guessing based on having to enable something that is not a default yet. It could very well be that Intel changed its implementation to require newer internals, i.e. older drivers providing EGL on top of DRI2 but currently transitioning to DRI3. > Is there no chance of it being buggy EGL implementation in plasma? I don't know enough to rule things out, but as far as I understand EGL's role is very limited from the application developer's point of view. It is basically just one of the ways to get OpenGL set up for work, the code that the developer then writes is the same as if they had used GLX for the base setup. It is just more likely that the EGL implementations, e.g. the one provided by the Intel, are updated more often than the respective GLX implementation and thus prone to bugs caused by change rather than being new. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
