-
Notifications
You must be signed in to change notification settings - Fork 90
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
refactor(cesium): reorganize featureconverter #853
Merged
jsalankey
merged 34 commits into
ngageoint:master
from
wallw-teal:refactor-cesium-feature-converter
Jun 26, 2020
Merged
refactor(cesium): reorganize featureconverter #853
jsalankey
merged 34 commits into
ngageoint:master
from
wallw-teal:refactor-cesium-feature-converter
Jun 26, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is largely a reorganization, not a rewrite or a change in logic. FeatureConverter was a spaghetti mess and hard to make sense of for anyone outside of a couple of experts. The general design for the refactor is shown in sync/convertertypes.js and sync/runconverter.js. The individual converter implementations are all pulled in by sync/converter.js. This is largely an attempt at feature-parity with the previous converter, with the following changes: - Several style bugs were fixed by consolidating and reusing style code where possible instead of using the previous one-off implementations - All functions being sent a feature, geometry, style, and context now have a consistent parameter order everywhere - A few minor performance items were added (typically things like using scratch arrays objects where possible) - All instances of @Suppress {checkTypes} were removed and fixed - Most larger functions have been split into smaller blocks with a couple of exceptions. I attempted to change anything outside of FeatureConverter the least amount possible (VectorSynchronizer and VectorContext) other than converting them to ES6 class syntax. FeatureConverter was previously entirely missing tests. WebGL mocks have been added and are fleshed out engouh that we can use a real Cesium scene in the tests. Many tests have been added but I still have more to write. Note that the tests currently require this PR: karma-runner/karma-googmodule-preprocessor#23
The coverage report will still be incorrect for goog module files but we have a separate ticket to address that.
The test errors are coming from the Cesium 1.65 merge. I'll look into those. |
That test is failing intermittently for me locally too. I'll look at it. |
schmidtk
reviewed
Jan 31, 2020
|
Most of those are fixed. I'm not totally happy with the icon stuff (there's a bit of a flicker to a larger size and back on rollover) and I'm continuing to try to improve that. |
stopping work to handle the forward-referenced type issue from the compiler
wallw-teal
force-pushed
the
refactor-cesium-feature-converter
branch
from
February 26, 2020 22:58
0a9b3ba
to
7527875
Compare
Also general cleanup in some other places as test coverage was added
Had to adjust our Cesium mixin for creatImage to work with fetch options rather than a simple string. Additionally, this new mixin is more targeted, allowing more of Cesium's image loading logic to run.
Also gate adding fills on fill alpha > 0. When removing fills, simply do not update the dirty flag on the item and let the update succeed with a noop.
In order to fix (many) DeveloperErrors in Cesium, lines no longer always use the same appearance, and rather only use the PolylineMaterialAppearance when a dash is used in the style. This allows for better performance in general, but now we need the isDashPatternChanging() method to check that the dashPattern is not defined (the correct value matching the else case of no PolylineMaterialAppearance).
Dunno what I was thinking before. This is way more readable. The idea is that the isFillBeingAdded check only runs once on the original primitive, but isFillBeingRemoved needs to run on each primitive as the method recurses.
Cesium prefers wide scene trees to deep ones, but there are several collection implementations that do not implement the 'show' property, preventing us from setting the visibility at the collection level (representing layer visibility). Therefore, these collections are added under a root PrimitiveCollection so that it's 'show' property can be used to properly control their visibility.
Using the underlying OL style to load the icon is problematic because ImageIcon applies color to the image. That's all well and good, but it requires setting the imageId in Cesium to 'src + color' rather than just 'src', which blows up the texture atlas. The solution is just to load the image directly and let Cesium color it. The downside is that custom extensions of those icon classes will not work properly (we do not currently have any).
for readability.
Points using RegularShape styles now (potentially) use less memory by keeping a single instance of the shape with a white fill, using the 'color' property of the billboard to color it. I say "potentially" because the full memory usage is still occuring on the OL/StyleManager side when the styles are created/updated. We could potentially add a mixin loaded by the Cesium plugin which could disable that since the billboards no longer need the original image style off of those.
Also added a test for the default color case.
MultiPolygonConverter was not properly detecting added fills, and falling through to PolygonConverter, while not passing it enough information to properly determine whether a fill is missing. Instead, do PolygonConverter's check for that before looping over the items and otherwise don't worry about it during the child loop (return false override).
After Cesium "loads" the image, whether that is an actual load over the network or retrieving the image from the texture atlas, we need to update the size on the style and have it reset/recalculate the normalizedAnchor and normalizedScale.
jsalankey
approved these changes
Jun 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is largely a reorganization, not a rewrite or a change in logic.
FeatureConverter
was a spaghetti mess and hard to make sense of for anyone outside of a couple of experts.The general design for the refactor is shown in
sync/iconverter.js
andsync/runconverter.js
. The individual converter implementations are all pulled in bysync/converter.js
.This is largely an attempt at feature-parity with the previous converter, with the following changes:
feature, geometry, style, context
now have a consistent parameter order everywhere@suppress {checkTypes}
were removed and fixedCesium.CollectionLike
of items (billboards, line primitives, polygon fill/outline primitves, polylines), we now only keep the root collections on the scene and keep track of the N items added per geometry.I attempted to change anything outside of
FeatureConverter
the least amount possible (VectorSynchronizer
andVectorContext
) other than converting them to ES6 class syntax.FeatureConverter
was previously entirely missing tests. WebGL mocks have been added and are fleshed out enough that we can use a real Cesium scene in the tests. Many tests have been added but I still have more to write.Note that for coverage reports to work on goog module files we need a change to the goog module preprocessor.
Testing
Basic Geometries
Ellipses and Ellipsoids
Tracks
Line String Tracks
Multi Line String Tracks
Altitude Mode
Extrusions
relativeToGround
for anything but points/icons (at least as far as I can tell) so anything marked "Relative" is really "Absolute" with the given altitude values.MultiPoint Volume