-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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: remove SymbolInstancesArray, SymbolQuadsArray #4217
Conversation
|
@@ -69,6 +69,7 @@ | |||
"remark-html": "^5.0.1", | |||
"request": "^2.79.0", | |||
"sinon": "^1.15.4", | |||
"st": "^1.2.0", |
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.
It's here. Is that dependency not working 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.
Ah. Yeah, it wasn't working for me -- e.g. the start-debug
script in the root package.json failed to find st
.
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.
Oh right, start-server
uses the st CLI. 👍
@lucaswoj @jfirebaugh @mollymerp This is mostly done, as discussed here: #4186 (comment). There's one render test mysteriously failing (because a road turned 180 degrees from waht's expected). Chasing that down now, but I think this is probably okay to 👀 nonetheless. |
This is awesome! |
3ae4de3
to
5fbb68b
Compare
These StructArrays were introduced with an eye towards the 'cross-source symbol placement' project, as a way to transfer all the information needed to re-place and then render symbols from the thread where each vector tile is parsed parsing occurs to the main thread for placement and rendering. However, data-driven styling presents a problem for this approach: for DDS, populating the paint attribute arrays requires both the feature property information (from the VT-parse thread) and the symbol layout information (because it dictates which features' paint attributes should be included). So, we aren't using SymbolInstancesArray (and SymbolQuadsArray) now, and will need a different approach when we revisit cross-source placement.
5fbb68b
to
26ce1f3
Compare
@lucaswoj rebased onto master - this should be good to go 🤞 |
* Refactor: remove SymbolInstancesArray, SymbolQuadsArray These StructArrays were introduced with an eye towards the 'cross-source symbol placement' project, as a way to transfer all the information needed to re-place and then render symbols from the thread where each vector tile is parsed parsing occurs to the main thread for placement and rendering. However, data-driven styling presents a problem for this approach: for DDS, populating the paint attribute arrays requires both the feature property information (from the VT-parse thread) and the symbol layout information (because it dictates which features' paint attributes should be included). So, we aren't using SymbolInstancesArray (and SymbolQuadsArray) now, and will need a different approach when we revisit cross-source placement. * Add missing st dependency * Remove unused quadCount member
We aren't using SymbolInstancesArray (and SymbolQuadsArray) now, and will need a different approach when we revisit cross-source placement, so this PR removes them, in favor of storing the necessary state down on each
SymbolBucket
instance (rather than at theWorkerTile
level).