From 8053f12b63e272cc9119a30f9ddc480b5ea75641 Mon Sep 17 00:00:00 2001 From: Florrie Date: Sun, 15 Sep 2019 17:17:31 -0300 Subject: Only render when stuff on-screen actually changes! This means we can basically guarantee 0% CPU usage when nothing on the screen is changing! There may still be some kinks to work out, but I've tested most features and fixed any apparent bugs (including an unrelated bug in the suspend feature which made it crash when resuming the process). --- todo.txt | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'todo.txt') diff --git a/todo.txt b/todo.txt index eba924c..6af1370 100644 --- a/todo.txt +++ b/todo.txt @@ -333,3 +333,40 @@ TODO: Default to 'after selected track' in context menu, and make pressing Q really only useful when you're building a queue at the start, assuming you don't start by shuffling your entire queue anyway). (Done!) + +TODO: When grouplike listings are fixLayout'd (e.g. the window is resized), + make sure the selected input is still visible! + +TODO: If you press any key which should select a particular element of the UI + (e.g. the menubar) while a context menu is open, currently the context + menu will close and then restore selection to the element which was + selected when the menu was opened. This seems to happen after the target + element is selected; the effect is that any key which is meant to focus + specific UI parts instead closes the context menu while one is open. + We already have a key for doing just that (the cancel key, i.e. esc or + period), so fix this! + +TODO: g/G should work for navigation in context menus! And probably all + ListScrollForms, tbh, but I'm kinda weary of introducing new behavior + like that to tui-lib. + +TODO: PageUp/PageDown support is complicated to implement (I've tried) and + should come eventually, but for now just make Home/End work as aliases + for g/G. This means making it possible for the keybinding system to let + a single input function return true for multiple different keys! + +TODO: Work out the BIGGER framerate shenanigans. Specifically: down with the + render interval! Or, more literally, get rid of it altogether. Only + render when we know the on-screen text is going to have changed. + (Done - Huzzah! We use 0% CPU when not actively updating the screen now.) + +TODO: Be more sneaky about how we decide what text to update on the screen, + in a way which saves us performance. Instead of going through the whole + ansi.interpret process, predict which regions of the screen are going to + have updated, and only process those spaces. We can guess reasonably by + looking at which elements caused the screen to update (keep track of this + in the Root, through the shouldRenderTo function). + +TODO: Create a basic Element class, which DisplayElement extends. We have a lot + of code related to scheduling displaying stuff on the screen, and it'd be + nice to keep it more separate from all the basic element logic. -- cgit 1.3.0-6-gf8a5