GNOME Bugzilla – Bug 694993
Random background allocations
Last modified: 2013-03-05 21:03:25 UTC
While working on bug 237789 I have noticed that one or more background groups keeps reallocation for no obvious reason: Clutter-Message: [ +30303]:[CLIPPING]:./clutter-actor.c:16876: Bail from get_paint_volume (<unnamed>[<MetaBackgroundGroup>:0x287ab80]): Actor needs allocation As we shouldn't be constantly changing the size or adding / removing children something looks not right here.
Can you track down which background actor is that? (Ie add a name, or fire gdb and look at it directly) Also, how do you get those messages?
(In reply to comment #1) > Also, how do you get those messages? CLUTTER_DEBUG=clipping (but do it from an SSH session or redirect to a file otherwise the output in the terminal causes redraws which causes output which causes redraws .... and the shell hangs at startup).
(In reply to comment #0) > While working on bug 237789 Should be bug 694988 (In reply to comment #1) > Can you track down which background actor is that? > (Ie add a name, or fire gdb and look at it directly) Yeah will try that.
Clutter-Message: [ 25357732693]:[CLIPPING]:./clutter-stage.c:4032: stage_queue_actor_redraw (actor=<ss_550>[<MetaBackgroundGroup>:0x1f32b10], clip=(nil)): Clutter-Message: [ +90]:[CLIPPING]:./clutter-stage.c:4032: stage_queue_actor_redraw (actor=<overview_195>[<MetaBackgroundGroup>:0x1f32e60], clip=(nil)): Clutter-Message: [ +165]:[CLIPPING]:./clutter-actor.c:16876: Bail from get_paint_volume (<ss_550>[<MetaBackgroundGroup>:0x1f32b10]): Actor needs allocation so screenshield and and overview ...
Ok, let's analyze this. Those background actors are parented to a BackgroundGroup, which uses a BinLayout with a fixed alignment. In the overview, each background group is parented to another BackgroundGroup, which in turn is parented to the overlay group (a ClutterActor with a FixedLayout). In the screenshield, each background group is parented to a StWidget with a FixedLayout, which in turn is parented to ScreenShield._backgroundGroup, a ClutterActor with a FixedLayout. This one is parented to a StWidget with a FixedLayout (_lockScreenGroup), inside another StWidget with a BinLayout (LayoutManager.screenShieldGroup). The overview background groups are positioned manually by BackgroundManager, while the screenshield ones are at 0,0 and the position/size are applied to their parent. Both actors are hidden normally, so they don't have valid allocations, but whenever visible they should not get queue_relayout unless you change the monitor configuration. In other words, I believe it is normal to get those messages when you open and close the overview or the screenshield, but at any other time, it would be a bug in Clutter layout managers.
(In reply to comment #5) > Ok, let's analyze this. > > Those background actors are parented to a BackgroundGroup, which uses a > BinLayout with a fixed alignment. > In the overview, each background group is parented to another BackgroundGroup, > which in turn is parented to the overlay group (a ClutterActor with a > FixedLayout). > In the screenshield, each background group is parented to a StWidget with a > FixedLayout, which in turn is parented to ScreenShield._backgroundGroup, a > ClutterActor with a FixedLayout. This one is parented to a StWidget with a > FixedLayout (_lockScreenGroup), inside another StWidget with a BinLayout > (LayoutManager.screenShieldGroup). > > The overview background groups are positioned manually by BackgroundManager, > while the screenshield ones are at 0,0 and the position/size are applied to > their parent. > Both actors are hidden normally, so they don't have valid allocations, but > whenever visible they should not get queue_relayout unless you change the > monitor configuration. > In other words, I believe it is normal to get those messages when you open and > close the overview or the screenshield, but at any other time, it would be a > bug in Clutter layout managers. OK makes sense; lets point ebassi at it to check whether this is correct and if yes what the layout bug is.
OK this might be worth noting here: This only happens when I use a non static background (i.e one that changes through the day). A static one results into sane (i.e small) redraw areas.
Created attachment 238161 [details] [review] background: don't use raise_top() since it's costly We currently resync the stacking order of the two key frames every iteration of the animation. This is costly and unnecessary. This commit ensures they're stacked properly up front and doesn't touch them after that.
Review of attachment 238161 [details] [review]: Makes sense and fixes the bug here.
Attachment 238161 [details] pushed as 020128b - background: don't use raise_top() since it's costly