(1) Found a regression on trunk when testing this. Will work on that now... bug 1420678.
(2) I'm concerned that "groups" are never useful or desirable with real displays;
If you use groups, support for displays with different refresh rates is lost. It's important that we never synchronize between different threads running different displays. Because one could easily be running much faster than the other (24Hz TV + 60Hz laptop in sidebyside mode) and still we need to be posting at the full 60Hz.
So groups in this way almost never make sense. I'm not sure it's a good idea for Android even. Definitely not desktop. Also, we already have a kind of grouping that we know is more annoying than useful; see bug 1395416.
(1) Found a regression on trunk when testing this. Will work on that now... bug 1420678.
(2) I'm concerned that "groups" are never useful or desirable with real displays;
If you use groups, support for displays with different refresh rates is lost. It's important that we never synchronize between different threads running different displays. Because one could easily be running much faster than the other (24Hz TV + 60Hz laptop in sidebyside mode) and still we need to be posting at the full 60Hz.
628 - display_ buffer_ compositor- >composite( scene_elements_ for(comp_ id)); ensure_ current( std::get< 0>(compositor) ); 1>(compositor) ->composite( scene-> scene_elements_ for(comp_ id));
629 - scene->
630 + for (auto& compositor : compositors)
631 + {
632 + target.
633 + std::get<
634 + }
635 + group.post();
So groups in this way almost never make sense. I'm not sure it's a good idea for Android even. Definitely not desktop. Also, we already have a kind of grouping that we know is more annoying than useful; see bug 1395416.