Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

port labeling, symbol sorting, and reparsing overscaled tiles #1666

Merged
merged 41 commits into from
Jun 3, 2015

Conversation

ansis
Copy link
Contributor

@ansis ansis commented May 29, 2015

this ports a bunch of stuff from -js:

This is finally close to merging. Sorry about the amount of changes in one pull request.

TODO:

I haven't noticed any stability problems but a lot has changed so this will probably introduce new bugs.

ansis and others added 30 commits March 30, 2015 17:48
Collision prevention is temporarily disabled.
line-height or padding can make the height of a shaped object <= 0.
In these cases either create no boxes, or create boxes with a minimum
height to avoid creating too many of them.

-js: 9e78c02d8b22b60a08fdb28fd29eef1642f62d94
Conflicts:
	src/mbgl/renderer/symbol_bucket.cpp
	src/mbgl/renderer/symbol_bucket.hpp
	src/mbgl/text/collision.cpp
	src/mbgl/text/glyph_store.cpp
	src/mbgl/text/placement.cpp
	src/mbgl/text/rotation_range.cpp
-js: e99ed95aaba5e79c322733b32e03518b12203a79
-js: 37a498a7aa2c37d6b94611b614b4efe134e6dd59
Conflicts:
	src/mbgl/map/tile_parser.cpp
	src/mbgl/map/tile_parser.hpp
	src/mbgl/renderer/painter.hpp
	src/mbgl/renderer/painter_symbol.cpp
	src/mbgl/renderer/symbol_bucket.cpp
	src/mbgl/renderer/symbol_bucket.hpp
	src/mbgl/text/collision.cpp
	src/mbgl/text/collision.hpp
	src/mbgl/text/placement.cpp
so that layout property functions are applied correctly
and so that label placement is redone

js:
mapbox/mapbox-gl-js#1005
and
mapbox/mapbox-gl-js@440bc02
@jfirebaugh
Copy link
Contributor

@ansis This doesn't work very well on device at the moment. It seems to stop loading tiles after a few gestures.

@ansis
Copy link
Contributor Author

ansis commented Jun 2, 2015

@jfirebaugh I just pushed 1f5fb1d which I think should fix that

@jfirebaugh
Copy link
Contributor

Yep, feels good now!

@bleege
Copy link
Contributor

bleege commented Jun 2, 2015

Same here. 👍 @ansis

@ansis
Copy link
Contributor Author

ansis commented Jun 2, 2015

A couple things should be reviewed:

@mb12
Copy link

mb12 commented Jun 3, 2015

1.) Is the following scenario handled?

a. worker starts doing replacement.
b. Tile becomes obsolete before worker thread doing replacement finishes.
c. worker should not call endRedoPlacement or somehow VectorTileData pointer should not be invalid when endRedoPlacement is called.

This will work in most cases because TileCache will hold a shared_ptr to VectorTileData. However this needs to work even when TileCache size is zero.

2.) Also does it make sense to do some testing with TileCache size as zero? Tile Cache may hide some bugs because it holds a shared_ptr to TileData.

@ansis
Copy link
Contributor Author

ansis commented Jun 3, 2015

  1. Yes, the TileData destructor calls TileData::cancel, which resets workRequest, which calls WorkTask::cancel. WorkTask::cancel clears the callback (endRedoPlacement) so that it doesn't get called when WorkTask::runAfter gets called later (it's definitely later, because it gets called on the same thread).

  2. Good idea. I tested it for a bit with cache size 0 and will keep that in mind for the future

thanks for the suggestions @mb12

@1ec5
Copy link
Contributor

1ec5 commented Jun 3, 2015

So far so good with visual inspection.

@jfirebaugh
Copy link
Contributor

redoPlacement uses workers safely

I don't see any glaring issues, but it's impossible to say much about thread safety conclusively, given the current structure. The TileData class hierarchy and worker code needs an overhaul to cleanly separate data on the worker thread from data on the map thread.

Style&,
GlyphAtlas&,
GlyphStore&,
SpriteAtlas&,
util::ptr<Sprite>,
const SourceInfo&);
const SourceInfo&,
float,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we name parameters when it's not clear from their type?

ansis added 2 commits June 3, 2015 19:17
and name parameters when it's not clear from their type
Conflicts:
	src/mbgl/renderer/painter_fill.cpp
@ansis ansis merged commit 9c03b39 into master Jun 3, 2015
@ansis ansis removed the in progress label Jun 3, 2015
@ansis ansis deleted the new-labelling branch June 3, 2015 23:35
@mb12
Copy link

mb12 commented Jun 7, 2015

@ansis Does redoPlacement need to be called at higher zoom levels? Specifically when (map's current zoom > SourceInfo.maxzoom + 1). Or is this handled in some other way to ensure good symbol density at higher zoom levels? (CollisionTileData.maxScale is const 2.0)

@ansis
Copy link
Contributor Author

ansis commented Jun 8, 2015

@mb12 this is handled in some other way. mostly by 1e044a1. For zoom levels > maxzoom, tiles from the maximum zoom level are reparsed completely. Layout properties can be functions and in order for these functions to work it needs to reparse those layers at every zoom level. It reparses entire tiles instead of only layers that need it because that was easier to implement.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants