From kde-panel-devel Mon Aug 31 12:16:08 2015 From: =?utf-8?q?Martin_Gr=C3=A4=C3=9Flin?= Date: Mon, 31 Aug 2015 12:16:08 +0000 To: kde-panel-devel Subject: Re: Review Request 124948: [screenlocker] Render greeter backgrounds as black Message-Id: <20150831121608.10622.3141 () mimi ! kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=144102341625786 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============8782078221377431889==" --===============8782078221377431889== Content-Type: multipart/alternative; boundary="===============0395468596104867683==" --===============0395468596104867683== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124948/ ----------------------------------------------------------- (Updated Aug. 31, 2015, 12:16 p.m.) Status ------ This change has been marked as submitted. Review request for Plasma. Changes ------- Submitted with commit 0da420f6309cdfa8dc95566a1afbf0f29a6b7ebe by Martin Gräßlin to branch master. Repository: plasma-workspace Description ------- The background of the whole screen locker architecture is black. During starting the lockscreen there might be a frame with just the background. To prevent flickering let's better use black instead of the default white. [screenlocker] Delay the async loading till first frame is rendered For the screenlocker architecture to work it's crucial that the views are shown as fast as possible with valid content. The OpenGL context initializes with a copy of the current framebuffer (which is the unlocked screen) and this is rendered as the first content of the lock screen and stays visible till QtQuick has rendered a proper scene. Initial rendering of our scene takes some time (> 500 msec) in which the unlocked screen stays visible, but the architecture thinks it's already fully locked and e.g. starts suspending the system. This can result in the system waking up with the screen looking as unlocked. This change ensures that at least one frame is rendered properly before starting to load the real scene in an async way. That's most likely just the black background which means the screen is properly locked, even if it is not the proper greeter yet. It's fine for the system to suspend in this stage as the screen is properly black. Diffs ----- ksmserver/screenlocker/greeter/greeterapp.h ed278e492a9a237f65f4c1600360f84fb25bdad7 ksmserver/screenlocker/greeter/greeterapp.cpp b500ba44c2b483d7372ca46840152c90ef5f798c Diff: https://git.reviewboard.kde.org/r/124948/diff/ Testing ------- Used kscreenlocker_test: now my screens all go nicely black and then later on swap to the greeter content. Thanks, Martin Gräßlin --===============0395468596104867683== MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124948/

This change has been marked as submitted.

Review request for Plasma.
By Martin Gräßlin.

Updated Aug. 31, 2015, 12:16 p.m.

Changes

Submitted with commit 0da420f6309cdfa8dc95566a1afbf0f29a6b7ebe by Martin Gräßlin to branch master.
Repository: plasma-workspace

Description 

The background of the whole screen locker architecture is black. During
starting the lockscreen there might be a frame with just the background.
To prevent flickering let's better use black instead of the default
white.

[screenlocker] Delay the async loading till first frame is rendered

For the screenlocker architecture to work it's crucial that the views
are shown as fast as possible with valid content. The OpenGL context
initializes with a copy of the current framebuffer (which is the unlocked
screen) and this is rendered as the first content of the lock screen
and stays visible till QtQuick has rendered a proper scene.

Initial rendering of our scene takes some time (> 500 msec) in which
the unlocked screen stays visible, but the architecture thinks it's
already fully locked and e.g. starts suspending the system. This
can result in the system waking up with the screen looking as unlocked.

This change ensures that at least one frame is rendered properly before
starting to load the real scene in an async way. That's most likely just
the black background which means the screen is properly locked, even if
it is not the proper greeter yet. It's fine for the system to suspend in
this stage as the screen is properly black.

Testing 

Used kscreenlocker_test: now my screens all go nicely black and then later on swap to the greeter content.

Diffs

  • ksmserver/screenlocker/greeter/greeterapp.h (ed278e492a9a237f65f4c1600360f84fb25bdad7)
  • ksmserver/screenlocker/greeter/greeterapp.cpp (b500ba44c2b483d7372ca46840152c90ef5f798c)

View Diff
--===============0395468596104867683==-- --===============8782078221377431889== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGxhc21hLWRl dmVsIG1haWxpbmcgbGlzdApQbGFzbWEtZGV2ZWxAa2RlLm9yZwpodHRwczovL21haWwua2RlLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BsYXNtYS1kZXZlbAo= --===============8782078221377431889==--