On Monday, May 9, 2011 19:31:30 Martin Gräßlin wrote: > * We need a context managment. We can no longer rely on only KWin creating a > context > * OpenGL ES backend could cause trouble if Qt pulls in desktop GL > and vice versa[2]. Does Qt uses a plugin approach?
none of this is given yet, and there are many possibilities; we can, and should, get involved in Qt5 design discussions sooner rather than later so we can be sure that our needs are heard and that we are aware of decisions that get made far in advance. > * With OpenGL becoming a requirement to run KDE software, we can go to > compositing only (we are no longer the only ones being slow/breaking the > desktop). this is the wrong argument imho. if we can appeal to a broader audience we should. just because others are limiting themselves doesn't mean we suddenly have license to as well. i think we first need to find out what it means when "Qt5 will require OpenGL" and how the approach taken interacts with the various drivers. just because the apps use OpenGL to deal with in-window 2D interfaces that reside in a single process (if that is indeed the path that gets taken; it might not be), that does not necessarily mean that we can assume compositing can be relied on. it could well end up that software fallbacks, albeit with the OpenGL API, are enough to drive the desktop apps. the same can not be said of kwin compositing. so before we go running of cliffs here (to soar into the sky or fall into the ocean :) let's be patient and find out where the cards will fall in Qt5 first. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
