2 ms·
This can also indicate a problem in architecture: if the monitor can go away any time, you shouldn't store long time references to it and instead, for example,
by codedokode 7y ago
This can also indicate a problem in architecture: if the monitor can go away any time, you shouldn't store long time references to it and instead, for example, call a function to get current default monitor every time you want to do something. Or at least validate those references before usage.
- jandrese 7y agoI suspect querying the monitor for its parameters every time you want to blit pixels to it is wildly impractical. EDID runs over a slow serial link, and you have 124.4 million pixels to blit out every second. The sensible way to handle this is for the system to throw an interrupt when the state of the connection changes, but interrupt handling is something Rust's ownership model struggles to accommodate.