QScreen vs. KScreen in plasmashell

[Daniel Vratil]

On Friday 24 of October 2014 10:15:00 David Edmundson wrote:
> On Fri, Oct 24, 2014 at 9:58 AM, Daniel Vratil <dvratil at redhat.com> wrote:
> > Hi all,
> > 
> > the current state of multi-monitor support in Plasma 5 is rather bad as
> > both
> > Plasma 5 and KWin keep crashing every time there's any change (+ the
> > desktop
> > is extremely sluggish for about 15 seconds after that). Many colleagues in
> > my
> > office would love to switch to Plasma 5 already, but this is one of the
> > major
> > blockers that scares most people away, so it needs to be fixed.
> > 
> > I was looking into plasmashell code to fix it (and also for a different
> > reason, more on that later) and realized that the code is mixing use of
> > KScreen and QScreen, and I couldn't resist asking myself why. QScreen
> > provides
> > subset of information that KScreen and all I can see in the code is just
> > endless conversion between QScreen and respective KScreen::Output and
> > hoping
> > they both behave the same. Would it make sense to get rid of QScreen
> > completely and use KScreen exclusively? I think it would solve most of the
> > crashes I'm currently getting.
> 
> I don't think it solves everything, there's a big XCB problem too.

Yep, seen that too, but more often I get crashes due to asserts or 
dereferencing null pointer from QScreen in plasmashell.

> 
> > I'm of course volunteering to do all the work,
> > but before I start, I want to make sure there's no real obscure reason for
> > keeping both QScreen and KScreen.
> 
> There are two reasons I can think of.
> 
>  1) So that the attached Screen property has the right info (
> http://qt-project.org/doc/qt-5/qml-qtquick-window-screen.html)
> 
> Related to this, MouseEventListener in kdeclarative returns a QScreen
> object in the mouse event, this /could/ be turned into a KScreen output but
> that requires work.
> 
>  2) For future High DPI support we can scale independently per screen. All
> QSGNodes of an item are wiped when it moves between screens and when they
> are recreated the scale factor /could/ be different.
> 
> (right now they're not, in 5.4 it's fixed between all screens, and plasma
> currently does it's own thing anyway, so arguably this isn't a very good
> reason)

Oops, I'm sorry, I haven't explained my idea properly: I am only interested in 
getting rid of QScreen in shellcorona.cpp and panelview.cpp, not in QML parts 
- I don't see a problem in using QScreen from QML as that seems to be working 
just fine (also it would get more tricky once KScreen objects are wrapped in 
QSharedPointers). My main concern was about the two CPP classes mixing reading 
information and getting change notifications from both QScreen and KScreen.

Dan

> 
> > Cheers,
> > Daniel
> > 
> > (For the "other reason I was looking into plasmashell": I'm currently
> > working
> > on a big KScreen API and design changes, which includes using
> > QSharedPointers,
> > having async API, and running platform backends in a separate process to
> > improve performance and stability, but I'll send a separate email on that
> > once
> > the API is finished, as that will affect all KScreen-enabled applications)
> > 
> > --
> > Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact,
> > #akonadi
> > Software Engineer - KDE Desktop Team, Red Hat Inc.
> > 
> > GPG Key: 0xC59D614F6F4AE348
> > Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
> > _______________________________________________
> > Plasma-devel mailing list
> > Plasma-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141024/2628946e/attachment.sig>