rpcs3
rpcs3 copied to clipboard
RPCS3
[Feature Request] UX improvements for debugging
- [ ] It would be nice if the host address of the CIA was shown on the debugger somewhere, so that I don't need to break within some function implementation via CE to maybe find it.
- [ ] It'd also be nice if the instruction highlighting in the debugger window was "fixed". It's extremely jarring and counter intuitive. If I select some instruction, I'm selecting that instruction, not that place in the list. It's just silly. I know it's done like this for performance reasons, but you could easily just save the address of the instruction that has been highlighted, then conditionally decide on each repaint if the instruction is visible or not, and highlight if it is. It's driving me more insane than Among Us.
- [ ] Please make the call stack copyable. I was informed it used to be, but then it was changed to an item list, and since then, you can only copy the first element's contents, even if you select every item in it.
- [ ] Enable "naming" certain functions, through the call stack's pane maybe? Could improve readability a lot while researching. Automatically substituting syscall/libcall names to these would also be pretty cool, on the off chance someone breaks in one. I'm not sure if such custom names should persist, and if so, how, though. It can also get pretty involved, since the pane is not actually a "call" stack, but a stack of LR values. Would need to be cognizant of function boundaries when doing renames like that, to make this feature actually useful.
- [ ] This is more of a memory viewer thing, but enable "naming" areas of memory, so that if they're loaded in to a register, it would show up in the debugger by that name maybe? E.g. you find the idk, health of your character in memory, so you name it "main_health", and in the debugger after loading the value, it would just show
main_healthmaybe, instead of the actual value? Didn't really give too much thought to this so far. - [ ] I'm not exactly sure, but are CTR based "calls" shown in the call stack? If not, could they be shown somehow? Maybe with some sort of designation added at the end too, like
(dynamic call), and for regular branches(static call)maybe? I'm kind of lost on this one, I'd definitely welcome some clarifications on this part. - [ ] Please add some titlebars to each window pane. It's pretty easy to see what's what, but it'd be just way nicer if no guessing was involved.
- [ ] Being pretty blind to how the debugger window functions internally, it seems to be going absolute ham while the game is running? It really doesn't seem to work out, the repaint performance is very subpar, and so it's struggling really bad. On top of that, refreshing once a monitor refresh, or on every other would be plenty enough too. If that's already how it works, and I'm really only experiencing the terrible UI repaint perf, sorry about that - then only that needs some sort of relief.
- [ ] Could function starts be visually separated in the asm? Like, preceeded by a line of emptiness perhaps. This is a pretty advanced request, if it would be way too much of a drag to add, I completely understand not wanting it in.
- [ ] Please make the right side of the thread selector dropdown menu tied to the edge of the container. It can bug out pretty hard and pretty often, hiding the thread names as a result.
I'm pretty open for discussion on most of these, if something is too hard to accomplish, I'll gladly take it off this list. It's also half bug reports, apologies for that.
What do you mean by repaint performance? Does it have increased CPU usage or something? If you mean watching a running thread, it's meant to repaint fast, but not too fast (about 100 ms, I forgot), in order to make it possible to notice what's going "in motion" on without actually pausing threads or other invasive actions.
He means something else. We render a Listwidget of fixed entry count. If we would render more items with a scrollbar, we would significantly decrease performance. That's why the item selection is fixed and doesn't change with a repaint/update. So he wants to manually update the Qt selection.
What do you mean by repaint performance?
The GUI itself is very laggy (for me). I hover over an instruction and I'll see it register around half a second later. It's just slow. This is only while running of course, so it's ultimately unimportant. Just a thing that bother's me, as it's a bad look, and makes it look like as if it was struggling, rather than just occasionally updating.
Repaint itself should be fast and consistent, ideally once a screen refresh. The update of the values painted in is what should be delayed, also consistently. I think the two are tied together right now? Due to this, things like hovering over an instruction in the disasm will appear slow.
