Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 23 hrs ago - more...
|
2018-01-09
, 14:07
|
|
Posts: 58 |
Thanked: 223 times |
Joined on Apr 2017
@ Germany
|
#62
|
I think I nailed the "during workout" problem.
The app calls the update function once every second. Normally this is no problem because the map is shown and the track is directly rendered.
But if the app is in background (phone is in standby), the update function is still called every second. And then when the app comes back to focus, the map plugin needs to render thousands of track points in a very short period of time.
This is all my fault. It does not make sense and is very unclean to do anything with the map if it's not viewed at all.
So I will modify the app so that only if the map is shown and active, things are done (update, center on current position, draw map icons).
The app calls the update function once every second. Normally this is no problem because the map is shown and the track is directly rendered.
But if the app is in background (phone is in standby), the update function is still called every second. And then when the app comes back to focus, the map plugin needs to render thousands of track points in a very short period of time.
This is all my fault. It does not make sense and is very unclean to do anything with the map if it's not viewed at all.
So I will modify the app so that only if the map is shown and active, things are done (update, center on current position, draw map icons).
|
|
2018-01-09
, 14:24
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#63
|
Originally Posted by jdrescher
Such scenario could lead to this effect, indeed. I doubt that openGL rendering functions are called while the app is minimized which could lead to accumulation of requests in the stack.
I think I nailed the "during workout" problem.
The app calls the update function once every second. Normally this is no problem because the map is shown and the track is directly rendered.
But if the app is in background (phone is in standby), the update function is still called every second. And then when the app comes back to focus, the map plugin needs to render thousands of track points in a very short period of time.
This is all my fault. It does not make sense and is very unclean to do anything with the map if it's not viewed at all.
So I will modify the app so that only if the map is shown and active, things are done (update, center on current position, draw map icons).
I think that I will still add a check when updating the source on whether the same source update is waiting in the stack. If it is, then the latest version will be used only. That should avoid these problems in future. But making an app a bit more conservative wouldn't hurt either.
|
|
2018-01-17
, 07:00
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#65
|
Originally Posted by piggz
@piggz, you would have to decode it first. Usually, you want to do something with the polyline in addition to showing it. So, I would expect that you would have to decode it anyway and there is no need to add support for decoding into the widget. Unless you have a good use-case where there is no need for decoding and you think that the functionality should be provided by the widget.
@rinigus How can I add 'google encoded polyline' to the mapbox widget?
So, as soon as it is decoded (there are codes around), add it to the widget as a source using addSourceLine (example commented out at https://github.com/rinigus/mapbox-gl.../main.qml#L260), add layer using addLayer and set its properties (see https://github.com/rinigus/mapbox-gl.../main.qml#L262 and below)
| The Following 3 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-01-17
, 08:10
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#67
|
Originally Posted by piggz
Its quite common to get this encoded polyline from remote services (same for Valhalla, for example). However, if you want to calculate something from it (like length, or find specific location), you would need to decode it.
@rinigus, im retrieving the data from a remote api (strava) and cant see why i woukd want to change it locally, however ill give your suggestion a go.
Let me know if you get into trouble.
| The Following 2 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-01-20
, 08:51
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#68
|
I have just released update for Mapbox GL QML plugin which should fix the issues exposed by Laufhelden.
Now, when pushing updates of the sources, the sources stack is checked whether any update is pending and, if it is, its dropped in favor of the new one. Has been tested against adding, updating and removing sources.
@jdrescher, would you mind to test whether it fixed also the issues woth longer workouts?
Update is available at OBS and OpenRepos.
Now, when pushing updates of the sources, the sources stack is checked whether any update is pending and, if it is, its dropped in favor of the new one. Has been tested against adding, updating and removing sources.
@jdrescher, would you mind to test whether it fixed also the issues woth longer workouts?
Update is available at OBS and OpenRepos.
| The Following 3 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-01-26
, 07:44
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#69
|
Just to let you know before I forget it.
I am going to skip QMapboxGL update v1.2.0 since it leads to blinking of the symbol on every update. The issue is described at https://github.com/mapbox/mapbox-gl-native/issues/10644 and has been fixed recently by https://github.com/mapbox/mapbox-gl-native/pull/10899
I expect that it will be incorporated into the next Qt release (QMapboxGL v1.3.0, source tree at https://github.com/mapbox/mapbox-gl-...ree/qt-staging). Then it will make it into QML plugin as well.
When this happens, the client programs would have to enable layout properties for the symbols that they wish to keep always visible:
Here, choose the one or both depending on whether symbol is shown with text and/or icon. For example, Poor Maps location indicator is done as a symbol and it will require it. If the location is shown as a circle, this is not needed.
You can already add these properties with the present version and all should work with v1.1.x as well. That way you would ensure that the code is future-proof.
I am going to skip QMapboxGL update v1.2.0 since it leads to blinking of the symbol on every update. The issue is described at https://github.com/mapbox/mapbox-gl-native/issues/10644 and has been fixed recently by https://github.com/mapbox/mapbox-gl-native/pull/10899
I expect that it will be incorporated into the next Qt release (QMapboxGL v1.3.0, source tree at https://github.com/mapbox/mapbox-gl-...ree/qt-staging). Then it will make it into QML plugin as well.
When this happens, the client programs would have to enable layout properties for the symbols that they wish to keep always visible:
Code:
map.setLayoutProperty("location-label", "text-allow-overlap", true)
map.setLayoutProperty("location-label", "icon-allow-overlap", true)
You can already add these properties with the present version and all should work with v1.1.x as well. That way you would ensure that the code is future-proof.
| The Following 4 Users Say Thank You to rinigus For This Useful Post: | ||