[Issue] Unnecessary window redraws

[maramadany]

Platform: Linux (Ubuntu 24.04)

CoreDeck seems to be constantly redrawing even when idle, which becomes very noticeable in software-rendered environments, one example of which is the virtual machine I used to test the program (notice the high CPU usage):

Admittedly this is more of a nitpicky 'correctness' issue, most people won't be running Android emulators under conditions where this causes major problems.

me:~/CoreDeck/build$ libglx=$(ldconfig -p | awk '/libGLX.so.0/{print $NF;exit}')
me:~/CoreDeck/build$ pid=$(pidof CoreDeck)
me:~/CoreDeck/build$ sudo bpftrace -e "uprobe:$libglx:glXSwapBuffers /pid == $pid/ {@swaps = count(); } interval:s:5 {print(@swaps); exit(); }"
Attaching 2 probes...
@swaps: 244


@swaps: 244

for reference:

me:~/CoreDeck/build$ cat testredraw.c 
#include <GLFW/glfw3.h>
#include <unistd.h>

int main(void) {

	if (!glfwInit()) return 1;

	GLFWwindow *w = glfwCreateWindow(640,480,"idle test",NULL,NULL);

	glfwMakeContextCurrent(w);
	glfwSwapInterval(1);


	while(!glfwWindowShouldClose(w)) {
		glClearColor(0.1f,0.1f,0.1f,1.0f);
		glClear(GL_COLOR_BUFFER_BIT);
		glfwSwapBuffers(w);
		sleep(1);
		glfwWaitEvents();
	}

	glfwDestroyWindow(w);
	glfwTerminate();
	return 0;

}
me:~/CoreDeck/build$ gcc testredraw.c  -o testredraw -lglfw -lGL
me:~/CoreDeck/build$ ./testredraw

in a different terminal:

me:~/CoreDeck/build$ libglx=$(ldconfig -p | awk '/libGLX.so.0/{print $NF;exit}')
me:~/CoreDeck/build$ pid=$(pidof testredraw)
me:~/CoreDeck/build$ sudo bpftrace -e "uprobe:$libglx:glXSwapBuffers /pid == $pid/ {@swaps = count(); } interval:s:5 {print(@swaps); exit(); }"
Attaching 2 probes...
@swaps: 0


@swaps: 0

Rerunning the last command while immediately putting the testredraw window in focus yields:

me:~/CoreDeck/build$ sudo bpftrace -e "uprobe:$libglx:glXSwapBuffers /pid == $pid/ {@swaps = count(); } interval:s:5 {print(@swaps); exit(); }"
Attaching 2 probes...
@swaps: 5


@swaps: 5

[devmuaz]

Good catch!

Tbh, using glfwWaitEvents() with sleep(1) would fix half the issue and introduce a bunch of other ones!
The reason why is that CoreDeck has a background state that the UI needs to reflect, even without user input:

• Emulator log streaming (new lines arrive from subprocess)
• IsRunning state changes when an emulator process exits
• Async prefetch of system images/device profiles
• Async install of system images

Pure glfwWaitEvents() would freeze the UI on those updates until the user moves the mouse.

Fix

What we want is a dynamic timeout based on what's actually happening:

while (!glfwWindowShouldClose(window)) {
    // NEW
    const bool focused = glfwGetWindowAttrib(window, GLFW_FOCUSED);
    const bool hovered = glfwGetWindowAttrib(window, GLFW_HOVERED);
    const double timeout = focused && hovered ? 1.0 / 60.0 : 0.25;
    glfwWaitEventsTimeout(timeout);
    
    // The rest of the code
}

Here's when the app is in Idle state

Here's when being focused Active:

I'd welcome a re-measurement on your end, and lemme know if the dynamic timeout introduces any UX regression you notice.
Replace this with the above code instead:

while (!glfwWindowShouldClose(window)) {
    // OLD
    glfwPollEvents();
    
    //Th rest of the code
}

Probably, we still need to use glfwPostEmptyEvent() to notify the UI when we have an active background state. I need to look into this more to see if we really need such an implementation!

Thanks a lot for bringing this up @maramadany

[maramadany]

The code snippet was used to demonstrate that the measurement was accurate, not presented as a fix, sorry if I didn't express that properly :)

I tested the fix and it is now indeed much better when idle:

me:~/CoreDeck$ libglx=$(ldconfig -p | awk '/libGLX.so.0/{print $NF;exit}')
me:~/CoreDeck$ pid=$(pidof CoreDeck)
me:~/CoreDeck$ sudo bpftrace -e "uprobe:$libglx:glXSwapBuffers /pid == $pid/ {@swaps = count(); } interval:s:5 {print(@swaps); exit(); }"
Attaching 2 probes...
@swaps: 20


@swaps: 20

[devmuaz]

Great!
Now, this has been fixed in this 4e584e8
For now, you can pull the develop branch and test it yourself!

Also, a PR #14 is already available to be merged into main as soon as I make sure everything works smoothly.
These changes will be available in the next stable release v0.2.0

I'm gonna be closing the issue, but feel free to reopen it at any time!

Thanks again for taking the time to review, test, and write such detailed reports!