Review Request 124948: [screenlocker] Render greeter backgrounds as black

Martin Gräßlin mgraesslin at kde.org
Thu Aug 27 08:48:05 UTC 2015


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124948/
-----------------------------------------------------------

Review request for Plasma.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150827/7fcddb5a/attachment.html>


More information about the Plasma-devel mailing list