Skip to content
This repository has been archived by the owner on Apr 10, 2018. It is now read-only.

v8 Omnibus #264

Merged
merged 40 commits into from
Sep 2, 2015
Merged

v8 Omnibus #264

merged 40 commits into from
Sep 2, 2015

Conversation

tmcw
Copy link
Contributor

@tmcw tmcw commented Mar 12, 2015

Patches:

JS, Native

Changes

@tmcw tmcw mentioned this pull request Mar 12, 2015
9 tasks
@tmcw
Copy link
Contributor Author

tmcw commented Mar 21, 2015

@lbud @quinnvd one thing I've always kind of wondered about the less-style operations (we used them directly in cartocss) was that

  • lighten & darken
  • saturate & desaturate
  • fadeout & fadein

Are basically duals: saying saturate: 10% means desaturate: -10% and you get the picture. Especially given that we'll be wrapping these in a UI, I think separating the negative and positive versions of the transform will just make downstream implementations weirder.

Thoughts?

@lbud
Copy link
Contributor

lbud commented Mar 24, 2015

@tmcw hm, true, and I see how if we use a slider UI centered at neutral this would make the implementation weird. But I also wonder if consistency from a Carto/LESS background is important.
cc @nickidlugash @samanpwbb @edenh — ?

@nickidlugash
Copy link
Contributor

@lbud Personally I'm in favor of prioritizing UI implementation over consistency with carto/LESS.

@samanpwbb
Copy link
Contributor

@nickidlugash @lbud regardless of how we end up doing this in the style JSON, the UI can do exactly what we want it to do. I was curious about this so I sketched it up:

https://github.com/mapbox/app-styles/issues/1352

Basically: show more fields and assume positive input values, or show less fields and assume both positive and negative input fields. Even if we include all the filters, we can still hide the 'negative' versions of the filters in the UI. I do believe if we implement a UI more like sketch 1, having both positive and negative options available would be better usability:

As a user, I know I want something to be desaturated. I'm going to look for "desaturate" first not for "negative saturate".

@tmcw
Copy link
Contributor Author

tmcw commented Mar 25, 2015

2015-03-25 at 2 19 pm

image

@samanpwbb
Copy link
Contributor

@tmcw I agree with you here, lets drop the inverse filters. It'll be simpler to implement in the UI.

@nickidlugash
Copy link
Contributor

I was thinking sliders, too.

@lbud
Copy link
Contributor

lbud commented Mar 26, 2015

Ok, so we'll pick saturate, lighten, and which fade one makes more sense to be positive? (I'm instinctively inclined to say fadein should be positive, although I would guess that's used less frequently…)

@samanpwbb
Copy link
Contributor

@lbud how about just 'fade' - positive values increase fade, negative values decrease fade?

@tmcw
Copy link
Contributor Author

tmcw commented Apr 14, 2015

Another modification for comment:

  • I think that we should support embedded sprite metadata: instead of pointing to a URL that contains sprite metadata, that data should be nested under the sprite key of the stylesheet.

@jfirebaugh
Copy link
Contributor

embedded sprite metadata

What's the rationale? I'm tentatively 👎 because previous discussions have pointed towards an omnibus format for sprites that combines images and metadata, which would either duplicate or obsolete style-embedded-metadata.

@tmcw
Copy link
Contributor Author

tmcw commented Apr 14, 2015

What's the rationale?

  • One fewer HTTP request to show each map
  • Easier & faster to do better stylesheet validation - validate that references to the sprite are valid
  • Simpler to implement in app-styles (okay, showing my hand with that one)
    • In our current implementation, to reference a style's sprite, we need to do a three-step process of saving the sprite, getting its id, building the sprite url with the id, and then resaving the style with a correct sprite url

@incanus
Copy link
Contributor

incanus commented Apr 14, 2015

Sprite metadata in the style feels bloated.

  • We already support two pixel ratios, and might do more. Even if we handle SVG sprites, we will always do rasters of some sort and multi-DPI just makes for a messy style section.
  • To clarify @jfirebaugh's point, we've talked (Treat "images" as nested collection of a style, like sources or layers #220) about a binary sprite storage format to reduce branching and increase performance. Being able to seek a sprite's metadata out of the store without having to pre-parse the whole store from a text format would unblock runtime sprite changes (such as a set of POI icons changing during a label language swap) or sprite attribute changes (such as toggling an icon theme as part of a POI level-of-detail change or a class toggle which affects icon style, such as color change in a night style).
  • We will invariably keep the imagery itself out of the style (base64 encoding or something similar would be a waste), so why split the imagery and metadata? One less HTTP request doesn't feel like a level trade given the complexity of having imagery and metadata in two places.

If sprites aren't valid in a style, just skip showing them? Easy way to point out a problem.

@tmcw
Copy link
Contributor Author

tmcw commented Apr 20, 2015

/cc @mapbox/gl

Can we schedule a v8 sprint directly after the gl-native code is shipped? To ship this, we need many more hands on deck.

@tmcw
Copy link
Contributor Author

tmcw commented Apr 20, 2015

Additionally: should we fold #276 Circle render type into this issue? I'm about to sketch out an implementation in gl-js

@lbud
Copy link
Contributor

lbud commented Apr 29, 2015

Grabbing types on native.

@lbud
Copy link
Contributor

lbud commented Apr 29, 2015

@tmcw should validate.constants also enforce that all constants have types?

@tmcw
Copy link
Contributor Author

tmcw commented Apr 29, 2015

y, i'll implement that.

jfirebaugh and others added 15 commits August 13, 2015 15:11
This happens in mapbox-gl-styles. Doing it here too creates a circular
dependency.
Conflicts:
	CHANGELOG.md
	package.json
- remove setConstant
- add setCenter
- add setZoom
- add setBearing
- add setPitch

Issue: #338
'pitch' follows 'center', 'zoom' and 'bearing' to define the default
camera position. 0 degrees is perpendicular to the surface.

Issue: #341
In new versions of Node and browserify `URL.parse()` URL encodes
properties on the resulting object. This has the effect of breaking the
migration script in the browser.

We can decodeURI the path segments we need to compare in a manner that is
backwards and future compatible.

Tested with:
- browserify
- Node 0.10
- IO 3.0
Every other layer type already supports visibility.
Types were made more specific to add extra type safety around constants.
Without constants, we no longer need these more specific types. Fewer,
well-known types makes tooling support easier.

- '*-enum' -> 'enum'
- '*-array' -> 'array'
- 'opacity' -> 'number'
- 'field-template' -> 'string'
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet