Merge lp://qastaging/~kaihengfeng/unity/lp1292830 into lp://qastaging/unity

The fix looks good to be but I would prefer to not use friends class and just expose a public method, e.g. just make WindowButton::UpdateTexture public.

Force pushed a new version to address the issue.

I'm, I see the approach here, but I'm not much a fan of some things...

You told me that instead of recalling set-texture on any element, just damaging its area isn't enough? What's the problem here?
Is this due to the fact that since the texture is saved as xrandr format, then the driver just deletes that on S3?

In any case I'd prefer that this thing would be done at DecorationsWidgets level so that it can be esily applied to all elements, and not just per item.

Let me know what's feasible, and I'll try to figure out the best approach, avoiding to be too much specific.

> I'm, I see the approach here, but I'm not much a fan of some things...
>
> You told me that instead of recalling set-texture on any element, just
> damaging its area isn't enough? What's the problem here?

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

Looks like the link in the commit log was mistakenly deleted when I did force push, here's the excerpt:

    The NVIDIA OpenGL driver architecture on Linux has a limitation:
    resources located in video memory are not persistent across certain
    events. VT switches, suspend/resume events, and mode switching
    events may erase the contents of video memory. Any resource that
    is located exclusively in video memory, such as framebuffer objects
    (FBOs), will be lost. As the OpenGL specification makes no mention
    of events where the video memory is allowed to be cleared, the
    driver attempts to hide this fact from the application, but cannot
    do it for all resources.

> Is this due to the fact that since the texture is saved as xrandr format, then
> the driver just deletes that on S3?

This I can't answer, but I think the excerpt above should've explained it.

> In any case I'd prefer that this thing would be done at DecorationsWidgets
> level so that it can be esily applied to all elements, and not just per item.
>
> Let me know what's feasible, and I'll try to figure out the best approach,
> avoiding to be too much specific.

The link gives a super simple example:

    create_gl_context();
    create_resources();
    while (1) {
        update_world();
        if (GetGraphicsResetStatusARB() == PURGED_CONTEXT_RESET_NV) {
            delete_resources();
            create_resources();
        }
        render_frame();
    }

I am not sure if it's feasible in current architecture though - maybe logind signal is the only way to go?

> > I'm, I see the approach here, but I'm not much a fan of some things...
> >
> > You told me that instead of recalling set-texture on any element, just
> > damaging its area isn't enough? What's the problem here?
>
> https://www.khronos.org/registry/OpenGL/extensions/NV/NV_robustness_video_memo
> ry_purge.txt
>
> Looks like the link in the commit log was mistakenly deleted when I did force
> push, here's the excerpt:
>
> The NVIDIA OpenGL driver architecture on Linux has a limitation:
> resources located in video memory are not persistent across certain
> events. VT switches, suspend/resume events, and mode switching
> events may erase the contents of video memory. Any resource that
> is located exclusively in video memory, such as framebuffer objects
> (FBOs), will be lost. As the OpenGL specification makes no mention
> of events where the video memory is allowed to be cleared, the
> driver attempts to hide this fact from the application, but cannot
> do it for all resources.
>
> > Is this due to the fact that since the texture is saved as xrandr format,
> then
> > the driver just deletes that on S3?
>
> This I can't answer, but I think the excerpt above should've explained it.
>
> > In any case I'd prefer that this thing would be done at DecorationsWidgets
> > level so that it can be esily applied to all elements, and not just per
> item.
> >
> > Let me know what's feasible, and I'll try to figure out the best approach,
> > avoiding to be too much specific.
>
> The link gives a super simple example:
>
> create_gl_context();
> create_resources();
> while (1) {
> update_world();
> if (GetGraphicsResetStatusARB() == PURGED_CONTEXT_RESET_NV) {
> delete_resources();
> create_resources();
> }
> render_frame();
> }
>
> I am not sure if it's feasible in current architecture though - maybe logind
> signal is the only way to go?

I would not rely on an extension that might not be available. Btw I guess Marco he's suggesting to apply the fix inside TexturedWindow, so removiong the logic from the *Manager class. You just need a way to get the "onResume" signal there.

Nvidia put the fixes back to 375 series [1], so we no longer need this merge proposal:

"Fixed a regression that caused corruption in certain applications, such as window border shadows in Unity, after resuming from suspend."

[1] https://devtalk.nvidia.com/default/topic/1007268/b/t/post/5141478