Closed onepiecefreak3 closed 3 years ago
For the memory efficiency, just making the ProgressElement into a struct would make it allocate on the stack and remove some GC pressure. Also only reporting every 100 blocks or so (and last block) would make it take less processing and still maintain good progress estimate (if UI needs to be refreshed on every call to Report
).
Should this have tests? Like launch a thread that monitors the progress and assert that the progress is always greater than or equal to the previous value. Then assert that progress is 100% once the operation is done.
Another thing I was thinking of is, wouldn't it now show progress for only the current mipmap level? Might need to calculate the totalblocks from all mipmaps first, then keep a cumulative count that stays between mipmap level encodes.
This adds a wrapper for the IProgress
I don't know if the progress behaviour is testable. Any ideas how that can be done?
The test can launch an async encoding method, and run a while loop afterwards. In the while loop the progress is checked that it is always equal to or greater than the previous progress values. After the operation is done, assert that progressed blocks is same as total blocks.
Also, the code looks good to me now. 👍
EDIT: ah you just pushed, I'll look again.
I think this feature can be merged now.
Yeah, it looks good to me.
This adds the progress feature based on the IProgress interface. It's not much but enough. Maybe it can be done more memory efficient?