My application opens an AsyncFileDialog and uses block_on to wait for it on another thread (it's easier to just spawn a thread and poll for completion every frame than pull in an entire async runtime).
However, the GTK AsyncFileDialog in particular seems to use 100% CPU on one of my cores while it's open. This doesn't happen if I run it synchronously or if I use the xdg-portal dialog instead. I'm not sure if I'm doing something wrong by using block_on--I've tried both the futures version and the futures-lite version of block_on and they both seem to try and park the thread yet consume 100% CPU anyway.
In addition, the GTK file dialog will very rarely hang when a file is selected and opened. This happens in both the sync and async versions, and it doesn't use any CPU--it successfully picks the file, hands control back to the application, and just never closes. This may be related to the above issue, but I'm not sure.
I'd prefer to use the GTK dialog if possible (the xdg-portal version doesn't respect the user's theme and sometimes takes several seconds to open).
valadaptive
commented
9 months ago
My application opens an
AsyncFileDialogand usesblock_onto wait for it on another thread (it's easier to just spawn a thread and poll for completion every frame than pull in an entire async runtime).However, the GTK AsyncFileDialog in particular seems to use 100% CPU on one of my cores while it's open. This doesn't happen if I run it synchronously or if I use the xdg-portal dialog instead. I'm not sure if I'm doing something wrong by using
block_on--I've tried both thefuturesversion and thefutures-liteversion ofblock_onand they both seem to try and park the thread yet consume 100% CPU anyway.In addition, the GTK file dialog will very rarely hang when a file is selected and opened. This happens in both the sync and async versions, and it doesn't use any CPU--it successfully picks the file, hands control back to the application, and just never closes. This may be related to the above issue, but I'm not sure.
I'd prefer to use the GTK dialog if possible (the xdg-portal version doesn't respect the user's theme and sometimes takes several seconds to open).