| Age | Commit message (Collapse) | Author |
|---|
|
ConnectionManager used to poll Cloud requests every second, while curl
requests were polled every 1/20th of a second. If curl request was over
at, say, frame #21, corresponding Cloud request would've only work with
that at frame #40 (950 ms later), which was making everything
cloud-related slower than it could be. This commit fixes it by making
Cloud polling period the same as curl polling period, and additionally
raises FPS to 25.
|
|
The cloud manager registers itself as an event source as a mean to be polled
periodically by the GUI or engine code. The periodical polling is used to
update the OSD icon indicating background sync activity.
Also move the cloud icon from ConnectionManager to CloudManager,
allowing to decouple icon handling from network connections updates.
|
|
|
|
|
|
I knew there were some, but I wanted to fix them once, instead of doing
it all the time.
|
|
|
|
|
|
Tried to use it everywhere I should've use it.
|
|
It now keeps newly added Requests in separate array, so iterators don't
break when one adds a Request while ConnMan iterates its array.
The array is also shielded with mutex.
|
|
It also shows a "sync disabled" icon in case it has a savepath override.
|
|
It's not a Request again, but still it controls ConnMan's timer.
|
|
CloudIcon is now a Request which is automatically added once first
Request is added to ConnMan. When icon decides it should disappear, it
gets FINISHED, so ConnMan would switch off the timer if it was the last
Request.
|
|
To achieve smoother animation, ConnectionManager's timer now is 20 times
more frequent.
I'm encountering some strange libcurl.dll segfault problem when I close
the application while some Requests are active. It's not
CloudIcon-related, so it's more likely related to this 20 FPS timer.
This problem shows up only in Visual Studio for me.
|
|
|
|
It now terminates active Requests.
|
|
It now keeps track of how many Requests are running.
To achieve that, we had to pass a callback to ConnectionManager, so each
Request has a callback paired with it. If that's one of Storage's
Requests, it has a callback, which would decrease a counter. When
Storage adds a Request, it also increases a counter and passes that
callback. Callback is called by ConnMan when Request is deleted.
isWorking() returns true if there is at least one Request running.
|
|
|
|
ConnectionManager now storages Request * (not generates ids for it),
Requests have control on their RequestState, RequestIdPair is now called
Response and storages Request * with some response together.
All related classes are changed to use it in more clean and
understandable way.
Request, RequestState and Response are carefully commented/documented.
|
|
Can be used with Callback<T> (means it's still type safe). It's used to
pass not only Request id to user's callback, but also a value user
wanted.
void *data field is removed from RequestInfo.
|
|
ConnectionManager upgrade: it now contains a special struct for each
request, so you can access request status and data by request id.
|
|
(Upgrading ConnectionManager step by step.)
|
|
With ConnectionManager singleton one can start their Requests without
creating Storage instance. Moreover, Storage instance should contain
cloud API, not Requests-related handling and timer starting methods.
Thus, these methods were moved into ConnectionManager itself.
|
|
This commit adds:
* ConfMan's new "cloud" domain;
* CloudManager's init() method, where it loads keys from "cloud" configs
domain;
* CurlJsonRequest's addHeader() and addPostField() methods;
* temporary Storage's printInfo() method;
* DropboxStorage's implementation of printInfo(), which is using access
token and user id;
* DropboxStorage's loadFromConfig() static method to load access token
and user id from configs and create a Storage instance with those;
* temporary DropboxStorage's authThroughConsole() static method, which
guides user through auth process from the console.
So, in CloudManager's init() implementation ScummVM checks that there is
"current_storage_type" key in "cloud" domain of configs, and loads
corresponding storage if there is such key.
If there is no such key, ScummVM offers user to auth with Dropbox.
That's done through console, and thus it's temporary (it also requires
restarting ScummVM twice and manually editing config.ini file).
|
|
Now it is based on MemoryReadWriteStream, which is introduced by this
commit. This stream is using ring buffer and is dynamically increasing
its size when necessary.
|
