The current state of EGL in KDE/Plasma

[Kevin Krammer]

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 at kde.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20160128/9d87e1d5/attachment.sig>
-------------- next 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.