fix(randr): avoid querying hardware to get current configuration (#2470)
When using `get_screen_resources`, XRandR will query the hardware to detect any change. This takes some time. `get_screen_resources_current` uses the cached information and is pretty fast. In my case, the information is always already present in cache because it was set by the program that did configure the screens (autorandr in my case, but this applies to most frontends). As polybar is not used to configure stuff, I think this is fine. There should be something configuring the screen before polybar is able to use it. However, maybe some people are using `polybar --list-monitors` just after plugging a screen. It won't display the new screen in this case. So, maybe this is not a good idea. It makes polybar starts faster (500ms faster in my case when there are 3 screens plugged). Also, I did this change because running `polybar --list-monitor` in parallel with starting `polybar` (in a for loop for example), I get some curious bug where my screens disappear and reappear. I don't need this change as this was easy to fix by avoiding the parallel access to XRandR properties, but maybe this would avoid other people running into the same problem. Your take!
This commit is contained in:
parent
06a3de0b89
commit
2cd0809a46
@ -145,7 +145,7 @@ namespace randr_util {
|
||||
primary_name = {name_iter.begin(), name_iter.end()};
|
||||
}
|
||||
|
||||
for (auto&& output : conn.get_screen_resources(root).outputs()) {
|
||||
for (auto&& output : conn.get_screen_resources_current(root).outputs()) {
|
||||
try {
|
||||
auto info = conn.get_output_info(output);
|
||||
if (info->crtc == XCB_NONE) {
|
||||
|
Loading…
Reference in New Issue
Block a user