Ark

i see what you mean though - when using the SDL port, when pausing the emulation, the GPU usage will drop to zero here. Good. i am on intel, using intel_gpu_top FYI, apparently, nvtop works on non-NVIDIA GPUs as well, despite the name. The package description on Arch reads "GPUs process monitoring for AMD, Intel and NVIDIA". I could not readily find intel_gpu_top in the Arch repos but I did find something called amdgpu_top which demonstrates the issue just as well, at least for AMD GPUs.

pause or not has no effect (which is also what i would expect, it renders the frame in either case) That is what I think should be different: While effectively paused, GPU power consumption should go down to idle level (4 W in my case). By the way, which value are you referring to? In my case, nvtop shows an overall power consumption value labeled "POW" at the top which is not process-specific. I am talking about that "POW" value. In order to see the difference I am talking about, it might be necessary...

Can you reproduce the issue? Also, I just noticed that pausing or using the monitor combined with minimizing the window brings power consumption down to where it should be. Using Fluxbox without compositing and (according to nvtop) an "AMD Radeon RX 550 / 550 Series".

Save power when emulation is paused

Okay, I think I have a quite concrete idea now. Also, I figured that the whole thing will be too big to fit into the normal prefs window so I think a separate window will probably be better. And since the "Edit external commands" window already features quite a lot of what we need for the design I propose here, I think it is be better to copy it, even though it means that the parts relevant for presets management will be there first. Also, this way, there is no need for a "(current)" preset. So,...

(Note: Assuming Arch and Xorg here. Not sure about Wayland but displaycal does not work properly when doing stuff with a colorimeter via xwayland. At least it used to be that way, not sure how things are today.) If monitor profile detection needs to be tested, use dispwin -I profile.icc (package argyllcms) to set the monitor profile. If successful, xprop -len 14 -root _ICC_PROFILE (package xorg-xprop) has something meaningful to say. There is an experimental function in PIL that detects a monitor...

Motivated by the scenarios described earlier, I would like to specify how I think color management should be controlled by the user. Let me first define some hypothetical GUI elements just so we can express this concisely. (How they will be implemented exactly is not important at this point.) A profile selector (PS) lets the user select between predefined profiles like "sRGB", indirectly defined profiles like "use default" or "use embedded" profile, and explicitly selected (ICC) profiles stored in...

Thanks for your animation experiments. According to https://github.com/python-pillow/Pillow/commit/f84684931d3e3ec0c9f6e1ff263fe7e51ee24013 , if I understand it correctly, a frame has a dict-like memberinfo with maybe a key duration. Maybe that helps understanding how the animation stuff in PIL works. If you feel like improving the image loading algorithm of MComix such that PIL can be used as an additional provider for animated images. that would be great! Also, it should probably go to its own...