-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moved Viewer functionality to CesiumWidget class #12202
Conversation
Thank you for the pull request, @jfayot! ✅ We can confirm we have a CLA on file for you. |
@jjspace Could you please take a pass on this PR and see if this is a direction we'd like to go API-wise? Please be mindful of any breaking changes, and deprecate or preserve functionality where we can. |
@jjspace any update on this one? 👀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jfayot, this is looking good. sorry for the delay, github doesn't make it very easy to review diffs for things that move between files... I had a few initial comments
I kept duplicate tests in ViewerSpec, may be some can be removed as they are implemented in CesiumWidgetSpec now?
Generally we don't write specs that test "dependencies" of an object. I would say any tests that are for viewer functions that are now just passed through to widget functions should be removed.
@@ -1887,24 +1754,11 @@ Viewer.prototype._dataSourceRemoved = function ( | |||
Viewer.prototype._onTick = function (clock) { | |||
const time = clock.currentTime; | |||
|
|||
const isUpdated = this._dataSourceDisplay.update(time); | |||
if (this._allowDataSourcesToSuspendAnimation) { | |||
const isUpdated = this._cesiumWidget.dataSourceDisplay.ready; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if you noticed this change, but I'm not quite confident with it, and I have no idea how to do it differently. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do remember thinking something about this seemed wrong but I forgot to loop back to it. I think it might be the case that this can be skipped because the onTick
for the CesiumWidget
checks the same thing and stops the same clock object if the data source display doesn't update? I also don't 100% understand what these functions are doing though so I might be wrong. Maybe we should even be initializing the clock
differently in the Viewer
now?
@ggetz would you be able to take a look specifically at this chunk of code/functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I understand, this block's intent is to temporarily stop the animation if something is still buffering into the dataSource. Since ClockViewModel
only pass through the Clock
's canAnimate
property, and the clock is already updated in CesiumWidget
, I first thought that this was no more needed into the Viewer.
To be sure, I did try to duplicate the test "suspends animation by dataSources if allowed" from CesiumWidget
spec to Viewer
spec (replacing widget.clock by viewer.clockViewModel) and removed the mentioned code block: the test failed!
I guess this is because the ClockViewModel
properties are not synchronized with Clock
's properties unless ClockViewModel.synchronize()
is called. Therefore, in the case where dataSource.update()
would return false, you would end up with clock.canAnimate
set to false, and clockViewModel.canAnimate
still equal to true.
May be the clockViewModel is being synchronized later but I can't be certain!
I left the "suspends animation by dataSources if allowed" test commented in the Viewer spec if you want to play with it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think this is a sensible change. Just as @jfayot stated, we need to update the clockViewModel
, which CesiumWidget
does not have a reference to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes @jfayot, I think this is getting pretty close. Just had a few more small comments.
I'm going to try and do a bit more testing tomorrow. For my sanity given that the Viewer
and CesiumWidget
are basically the "core classes" of CesiumJS and used by every project I'd feel more comfortable with a second review pass, maybe @ggetz or @lukemckinstry can take a look through?
@@ -1887,24 +1754,11 @@ Viewer.prototype._dataSourceRemoved = function ( | |||
Viewer.prototype._onTick = function (clock) { | |||
const time = clock.currentTime; | |||
|
|||
const isUpdated = this._dataSourceDisplay.update(time); | |||
if (this._allowDataSourcesToSuspendAnimation) { | |||
const isUpdated = this._cesiumWidget.dataSourceDisplay.ready; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do remember thinking something about this seemed wrong but I forgot to loop back to it. I think it might be the case that this can be skipped because the onTick
for the CesiumWidget
checks the same thing and stops the same clock object if the data source display doesn't update? I also don't 100% understand what these functions are doing though so I might be wrong. Maybe we should even be initializing the clock
differently in the Viewer
now?
@ggetz would you be able to take a look specifically at this chunk of code/functionality?
Hi @jjspace ! I'll be off for one week starting from now with no connectivity at all... |
Started some initial high level testing, on sandcastles like this https://sandcastle.cesium.com/?src=GeoJSON%20simplestyle.html when using this branch should we be able to replace |
@lukemckinstry The basic answer is yes. After this PR the API for Swapping it in that one you linked works fine for me, were you seeing an issue? I had tried on a handful of sandcastles already but if you see specific issues please share them so we can take a look. |
I did see an issue in that sandcastle, but it is working fine now 👍, so perhaps I set it up wrong |
Hi @jjspace, I'm back 😁 |
Awesome, thanks @ggetz! @jfayot Can you please merge in main to make sure there are no more conflicts? Then update the Overall with our previous reviews I think this is really close. I'll take another look once the branch is updated! |
@jjspace @ggetz, I've rebased my branch and updated the CHANGES.md. I also tried to improve the way canAnimate is updated in the _onTick using a callback. The test "suspends animation by dataSources if allowed" was duplicated in both Viewer and CesiumWidget in order to test it in both context. Hope this is fine for you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay on this @jfayot. All looks good to me now, thank you for the changes!
Description
This is a proposal to move Viewer functionalities not related to widgets to CesiumWidget class as proposed in #11967.
Issue number and link
Fixes #11967
Testing plan
I kept duplicate tests in ViewerSpec, may be some can be removed as they are implemented in CesiumWidgetSpec now?
Author checklist
CONTRIBUTORS.md
CHANGES.md
with a short summary of my change