mirror of
https://github.com/ARMSX2/ARMSX2.git
synced 2026-08-24 16:50:16 -07:00
jpolo1224
d2a7613fb3
Custom panel background. Theme / library / black covered three of the four asks; "an own background" needed a picker. Takes the persistable read grant like the library's own picker -- without it the URI works until the process restarts and then resolves to nothing, which reads as the background disappearing on its own. Darkened by the same scrim as the library backdrop, because an arbitrary photo has no obligation to be dark and tile text still has to be readable. Clock and battery move into a status bar across the top instead of being two grid cells. Same information, but it stops the clock competing for space with the things you actually press, and the grid gets two cells back. The rest of the in-game OSD's figures reach the panel: VPS, EE / GS / GPU load and frame time. These were not missing by choice -- getFPS() was the only figure with a way across the JNI boundary, so the panel could show frames and a percentage of nominal and nothing else. PerformanceMetrics already computed all of it for the overlay. Each getter returns 0 with no VM rather than the last value, so an idle panel reads as idle instead of frozen on whatever the last game was doing. Tile height is now settable. Columns already decided width -- tiles split the row equally, so choosing columns IS choosing width, and a second width control would only be a way to disagree with it. Height had no control at all, which is why a panel could only ever be as tall as its text. A display can be told to stay out of it. "The second screen also still appears on the external monitor when connected via usbc" is not a bug by the display-picking rule -- a USB-C monitor is a perfectly good second display -- so this records a preference instead of guessing: the panel's own Not-this- screen tile drops the display it is on, and settings can re-enable them. Keyed by display NAME, since ids are reassigned across replugs. Guessing from internal-vs-external would have been wrong anyway; Android has no stable public display type before API 34. Device temperatures on the performance overlay, which is where they were asked for. The core cannot read a temperature -- there is no portable API, and on Android the only route is a vendor-specific sysfs the app layer already discovers for the panel -- so the app pushes the values in and the overlay draws what it was given. Atomics because the writer is a UI-thread poll and the reader is the GS thread. A sensor that could not be read is omitted rather than drawn as a zero.