Unlocking the phone over fullscreen app is very slow

When locking phone with dialer in front, I see it tries to make itself fullscreen

qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0x1c36080 state=fullscreen
qtmir.sessions: Session::setFullscreen - session= qtmir::Session(0x1b2e608) fullscreen= true
qtmir.applications: ApplicationManager::onAppDataChanged: Received "fullscreen" update

and then on unlock of phone, it un-fullscreens itself

qtmir.sessions: Session::setFullscreen - session= qtmir::Session(0x1b2e608) fullscreen= false
qtmir.applications: ApplicationManager::onAppDataChanged: Received "fullscreen" update
qtmir.surfaces: MirSurfaceItem::updateMirSurfaceSize surface = qtmir::MirSurfaceItem (this = 0x20f9850 , name= "" , parent = 0x19c2078 , geometry = QRectF(0,0 768x1222) , z = 1 ) , old ( 768 , 1280 ) , new ( 768 , 1222 ) surface resized

Is dialer fullscreening itself on lock?

>> Is dialer fullscreening itself on lock?
<mterry> greyback_, yes
<mterry> greyback_, well the greeter enforces fullscreen / locked-down UI when you're in the emergency dialer (doesn't present launcher or indicators). So the dialer requests fullscreen because otherwise there'd be a blank bar at the top where the panel used to be
<greyback_> mterry: could it fullscreen itself only when it needs to appear?
<mterry> greyback_, well hm. I don't think we send it any signals that it could pick up on
<mterry> greyback_, unless it wasn't top app, then it would notice that it was being focused

The fullscreen/unfullscreen change appears to be a performance hit on shell while it's trying to animate lock screen. Resize isn't fast, hits CPU mostly. Not sure how, but might be optimisable.

Alternative is that Shell could refuse to honour fullscreen requests if device locked. But would be racey on unlock - what would happen first, the unfullscreen request from the client, or the shell's "oh I need to fullscreen you now"

This is rather visible because it happens at least every time you answered a call and unlock the phone afterwards, so we'll need to think about solving this soon.

An easy but not necessarily pretty fix is to revert the commit that added greeter-fullscreen switching to the dialer [1]. It will leave us with a black bar where the panel is, but that's probably better than a jittering experience.

Of course a real fix would be better. Either make this change quicker (do we think it's actually a complicated operation or just poorly performant?), or only have it make the change when needed (i.e. we actually expose the greeter) instead of every time the greeter shows. Or both.

For the latter, we'd probably need some way to signal what's happening. Maybe an exposed DBus property much like "Active" but named something like "Shown" to indicate if the greeter itself is visible.

[1] http://bazaar.launchpad.net/~phablet-team/dialer-app/trunk/revision/321

Problem is that the Lockscreen height is defined like this:

    Lockscreen {
        y: panel.panelHeight
        width: parent.width
        height: parent.height - panel.panelHeight
    }

and Lockscreen contains:

    Image {
        // Limit how much memory we'll reserve for this image
        sourceSize.height: height
        sourceSize.width: width
        fillMode: Image.PreserveAspectCrop
    }

panel.panelHeight is a property which is animated during unlock, if the application is fullscreen. Animating sourceSize is a bad thing, as it causes the CPU to rescaling the image each time.

I can't repro this any more. Closing