<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 9:58 AM, Daniel Vratil <span dir="ltr"><<a href="mailto:dvratil@redhat.com" target="_blank">dvratil@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
the current state of multi-monitor support in Plasma 5 is rather bad as both<br>
Plasma 5 and KWin keep crashing every time there's any change (+ the desktop<br>
is extremely sluggish for about 15 seconds after that). Many colleagues in my<br>
office would love to switch to Plasma 5 already, but this is one of the major<br>
blockers that scares most people away, so it needs to be fixed.<br>
<br>
I was looking into plasmashell code to fix it (and also for a different<br>
reason, more on that later) and realized that the code is mixing use of<br>
KScreen and QScreen, and I couldn't resist asking myself why. QScreen provides<br>
subset of information that KScreen and all I can see in the code is just<br>
endless conversion between QScreen and respective KScreen::Output and hoping<br>
they both behave the same. Would it make sense to get rid of QScreen<br>
completely and use KScreen exclusively? I think it would solve most of the<br>
crashes I'm currently getting. </blockquote><div><br></div><div>I don't think it solves everything, there's a big XCB problem too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm of course volunteering to do all the work,<br>
but before I start, I want to make sure there's no real obscure reason for<br>
keeping both QScreen and KScreen.<br></blockquote><div><br></div><div>There are two reasons I can think of.</div><div><br></div><div> 1) So that the attached Screen property has the right info (<a href="http://qt-project.org/doc/qt-5/qml-qtquick-window-screen.html">http://qt-project.org/doc/qt-5/qml-qtquick-window-screen.html</a>)</div><div><br></div><div>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.</div><div><br></div><div> 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.</div><div><br></div><div>(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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Daniel<br>
<br>
(For the "other reason I was looking into plasmashell": I'm currently working<br>
on a big KScreen API and design changes, which includes using QSharedPointers,<br>
having async API, and running platform backends in a separate process to<br>
improve performance and stability, but I'll send a separate email on that once<br>
the API is finished, as that will affect all KScreen-enabled applications)<br>
<span class=""><font color="#888888"><br>
--<br>
Daniel Vrátil | <a href="mailto:dvratil@redhat.com">dvratil@redhat.com</a> | dvratil on #kde-devel, #kontact, #akonadi<br>
Software Engineer - KDE Desktop Team, Red Hat Inc.<br>
<br>
GPG Key: 0xC59D614F6F4AE348<br>
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348</font></span><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br></div></div>