|
Re: App for vector renderer maps, using OpenGL ES 2.0
Rinigus, how do you have it running on OnePlus X? I can't install as there are no OS updates past 2.0.2.51.
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
So far, I found out that : qgeomap.cpp adds all those items in a "m_mapItems" list as "QDeclarativeGeoMapItemBase" As subclass called "QDeclarativePolylineMapItem" is in charge of the Polyline element, which is then drawn directly with OpenGL calls on top of the map. This uses an internal "MapPolylineNode" class, which is doing the OpenGL call (things like "geometry_.setDrawingMode(QSGGeometry::DrawTriangl eStrip);" )., through the "geometry_" variable. The QDeclarative*MapItems (polylines, polygons, ...) exist from Qt 5.0 from the documentation, so it may be possible to restore this functionality by making the MapboxMap a derivative of the GeoMap class, and adding some glue (if the one from 5.6 has enough) ? The second way would be to code that behavior in a custom class, like MapboxMap, but keeping the raw GL way (to let the GPU handle the coordinates changes, and not computing them by hand which would be difficult). And then, there is the solution rinigus presented, to add a layer through GeoJSon to do this in the MapBoxGL Engine. I am not sure yet what the advantages and drawbacks of each solutions are, especially the overhead of adding a layer compared to a few direct GL calls. Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Translating in commands, for future me (and other who could need to): Quote:
Code:
devel-su ssu addrepo mer_rinigus http://repo.merproject.org/obs/home:/rinigus:/maps/sailfish_latest_armv7hl/ Quote:
Is there another gdb command output you need ? (my gdb is a bit rusty...) Quote:
It is usually one variable stored above in the memory that got out of its bounds, but can be more subtle. This can be "quite easy" to find in a small micro-controller, but I don't know how to show it in that case, as there are a lot of allocation/deallocation happening and so it can be difficult to know what was in memory before when the problem happened. Especially as valgrind doesn't run, from your tests. Some basics tests could be done, like adding tests around all mallocs and pointers usage, leading to a qFatal() call to stop the application with a core dump and details. However, if the problem is on the GPU side (as only the adreno 200 shows it right now), it would not help that much.. |
Re: App for vector renderer maps, using OpenGL ES 2.0
For me as well, with Jolla 1, it crashes, as soon as I interact with the map. I'll leave debugging to more capable hands. On the tablet, everything looks fine.
Device: Jolla Tablet SFOS version: 2.1.1.26 Did it crash? No Is the map displayed properly? Yes Are the names rendered? Yes Does movement work? Yes Does zoom work? Yes Does rotation work? Yes Does tilting work? Yes |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Quote:
Quote:
BTW, any idea if the markers could be made clickable ? Some generic "marker <id> clicked, with id set/provided at marker creation would be enough. Otherwise it would be tricky to resolve which marker the user has clicked on due to rotation/animation/camera angle, etc. Not are a blocker though as there are ways to address the markers even when they are not clickable, by eq. showing a list, etc. Still would be nice to have & is IIRC already possible with current solutions in Poor Maps and in modRana. :) Quote:
On the other hand I wonder - how hard it would be to also support map tiles in the Open GL widget ? That way you could use specialized tiled map layers (traffic, weather, OSM bugs, etc.) on top of the rendered map layer or even just use tiled maps directly with all the benefits of an Open GL based map widget. It would also mean mapping apps could eventually drop their solutions for tiled maps as the Open GL map widget would cover that as well. As an example of an Open GL based tiled map widget, Cloud GPS had that oh so many years ago back on the good old N900: https://talk.maemo.org/showthread.php?t=58402 https://vimeo.com/16748976 But in any case no pressure - this is just a nice to have feature while the widget already provides a lot of pretty cool stuff & there is certainly much more things that need to be solved. :) Quote:
Quote:
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
As for comparison in terms of features: using GeoJSON we can position the added features in between the map layers. As far as I could understand, you style the added features using the same styling as you do for the map. For example, its possible to add calculated road as a layer after the road on the map but before road names layer. As a result, your calculated road is visible, but does not cover road names. As a limitation, it was mentioned that MapboxGL added layers don't support transparency. However, with the ability of positioning the layer accordingly, I don't think its a problem. There is one complication that has to be taken into account while writing a widget - QMapboxGL object lives in the rendering thread, not main thread. We can have an access via update method of the widget when you are allowed to sync, but otherwise its "no touch" condition. The second complication is that, in SFOS, when you minimize the application, the corresponding OpenGL scene is destroyed. So, when the application is restored, the widget is constructed again and we have to add all the layers/sources/paint properties. I am writing now the part that will keep track on sources/layers/ and other properties and would patch or play back all the needed (non-removed) features on construction. It would probably take few evenings to implement it, but nothing really major. When ready, I'll make a new demo. Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
onClickEvent: you ask for coordinate via async mechanism. Something like "map.getCoordinates(my_tag_as_string, qpoint) you get reply via signal: onCoordinatesRequest: point Then you could implement adding of other widgets on the top which will allow you to interact. Tricky with panning/rotating/tilting though. Maybe the map programs would just remove widget on rotation,tilting and follow panning signals to move it around. I would prefer to keep out from GeoJSON parsing and figuring out what did you add there. Maybe widget-added POIs could get extra support, but let's see when we get there (later this week?). Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
I will be updating test results in this post as they come along. Only SFOS with Qt 5.6 is supported (2.1.x.y and higher), hence I am not reporting issues with the earlier SFOS versions.
All works:
Failed
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
When I open your app on Jolla 1 without access to internet everything is ok but after enabling internet connection, map loading and output of journalctl starts to look like this:
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
note : when launch as nemo journalctl gives the misleading message that no jiurnal is found, not that it has no rights to open it. it have to be opened as devel-su. options -f allows to keep it displaying only new messages (like tail) , and -l allows to output full line otherwise it cuts them when too long. so, with devel-su journalctl -fl, I get : Code:
sept. 20 01:02:47 Sailfish kernel: kgsl kgsl-3d0: |kgsl_iommu_fault_handler| context = 0 FSR = 4000000A |
Re: App for vector renderer maps, using OpenGL ES 2.0
I submitted the issue at mapbox-gl-native repository, let's see if they can guide us. Used the kernel messages in the description, hopefully they contain most of the info.
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
I will follow it closely to see if they need some other tests/traces. For references for other who would want to follow it too, here is the issue link: https://github.com/mapbox/mapbox-gl-native/issues/10029 |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
I'll continue coding the widget and work on testing it. When we start getting map client(s) adopting it, the exposure to the problem will increase and maybe someone skilled in GL ES will look into it. J1 is rather old and non-support for J1-type hardware will disappear eventually :) |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Quote:
I can still help a bit with the desktop version then (and can still test with the J1, but I have no other Sailfish phone). Do you have some kind of roadmap or task list, to see how we could "share" tasks (taking into account you work 100 times faster than me...) ? |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Still might not be always doable, for example if centering is enabled & centering is animated. That way there would basically be no time as which to show the custom widgets as the Open GL widget would be animating & asynchronously changing to arbitrary coordinates all the time. There could still be workaround but I'll likely just try to use the polyline/polygon/marker API where possible. :) Quote:
A rough outline what would enable modRana support it's current map overlay feature set: * position indicator API - show current position & the direction of travel - turn position display on/off This is how the modRana position indicator looks like: http://modrana.org/images/modrana_po..._indicator.png * POI marker API usecase: show POI on the map - add/remove markers given as a lat/lon coordinate with a label - each marker should likely have an unique id (app provided/returned by function call ?) - would it be possible to make the marker label clickable ? (eq. a markerClicked signal returning the id of the marker if callback registration would be too complicated) - in general the markers & labels should be drawn on top of any polylines or polygons if possible BTW, this is how modRana created POI markers look at the moment: http://modrana.org/images/modrana_poi_marker.png * polyline API usecases: show tracklogs, navigation routes, live logging trace - add/remove polylines given as ordered lists of lat/lon coordinates - again they should have unique IDs - for drawing routes it would he handy to be able to supply also a second list of points that would be highlighted on top of the polyline (turn points) - alternatively this could be emulated by drawing POIs without labels for the turn points, requiring a bit extra map object management code on the application side - for the specific use case of drawing on map trace/live logging trace (eq. basically a live trail of last visited points) an appendable polyline would be nice, if possible, as removing/adding a new polyline every location update would likely not work very well - or there could be a special built-in "trail" polyline that would automatically track current location and could be turned on/off - that way it should be possible to avoid the trail lagging behind the position indicator ModRana currently draws routes like this: http://modrana.org/images/modrana_route_display.png The yellow points are turn points and the red/green circles are start/destination designators. Tracklogs & logging traces look similar, but don't have the turn points and start/destination designators. * polygon API use cases: show areas of interest, map area selection - add/remove polygons given as ordered lists of lat/lon coordinates - again they should have unique IDs - color selection would likely by handy to tell polygons apart - labels are likely not needed - one can just place a labeled marker inside the polygon ModRana currently does not draw polygons on the map. :) This is just a rough outline and feedback from other potential users of the widget is certainly welcome! :) Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Additional help would be reading what is actually possible. I am new to Mapbox GL and I am learning by doing this interface. I wouldn't be surprised if many of MartinK requests are already supported via Mapbox GL. Not that you have to rewrite the docs, but help when we get requests on whether one or another thing is possible and help to write simple-to-use wrappers that map applications can use (add route, position marker, pois, ...) |
Re: App for vector renderer maps, using OpenGL ES 2.0
MartinK: I guess we'll get back to your post when the elementary support for adding objects is there :)
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
@Zeta: the first version with the support for updating the map with the sources, layers, ... is out in github repo. You are very welcome to test it, I haven't had a chance to do it myself. Current interface is at qquickitemmapboxgl.h - I will continue adding missing methods and then would be able to test as well.
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Watching this thread intently, and will lend aid/test wherever needed.
Very exciting stuff! |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
I can see some polyline drawn over helsinki, in a white dash-dot pattern, if that was what you expected. I tried some changes, and I succeeded in generating this polyline data from C++ (as a QVariantMap with the geojson data), then adding it on the map layer on the QML side. I will try to do it with a real route, as would be generated by OSRM or another routing engine, to have something more complex than what I have done by hand and see if it breaks at some level. And then make the connections so that changes on the route are updated on the map. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
So far, I had only be playing with your demo app, making some changes here and there to so see what it could do, but I have now started to work on a real use case of the qml map. I will push it later on Github. So, some quick comments: I have easily taken OSRM route output (as GeoJson) and added it as a new layer on the fly. Adding a geoJson route of 1800 points (corresponding to the "full" output option of OSRM for a route of a bit more than 100 km), doesn't introduce visible slowdown on PC. I am downloading the full France PBF to make tests with longer routes (a thousand km is possible through France). Behaviors on zoom and pitch properties are working great ! Adding those lines allows to switch from a route overview to a car-like navigation view seemlessly: Code:
Behavior on zoomLevel { NumberAnimation { duration: 1000 } }Code:
map.center = QtPositioning.coordinate(60.16 + 0.01*Math.sin(angle), 24.94 + 0.01*Math.cos(angle))My next step is to allow OSRM to update the route it added previously, which shouldn't be too hard. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
I have seen the same flickering when I moved the center in accordance with the dot. Same flickering is visible when you drive around and set gps location to be on the center (but it seem that the gps coordinates are updated not that frequently). I did some testing and couldn't see improvements when I set the center and position of the dot at the same time. However, I might have done something wrong during it, would have to recheck. I have started to use issues as some crude todo list. Added this flickering to it as well. |
Re: App for vector renderer maps, using OpenGL ES 2.0
I think that large chunk of API is ready. Its not stress-tested, but can be used as a solid starting point for it.
The missing piece is an API that would allow to add interactive elements on top of the map. I have an idea on how to make it and will probably implement in the next couple of evenings. Present API follows the logic of map drawing by Mapbox GL and is somewhat different from what we used so far (before we couldn't draw within the map, just on top). So, few terms and what's supported: * you can rotate, pan, zoom, and tilt * you can set the "center" of map into any position of the widget. For example, get the center in the middle (when just looking where you are) or in the lower bit of the screen (when you drive). This is supported via margins * To add anything to the map (and here the magic comes), you need to add source and layer. Multiple layers can use the same source. * Sources supported by QMapboxGL are GeoJSON and probably few others, but this has to be researched if needed. I think you could add tiles as well, but I haven't looked into it. * Sources in GeoJSON can be fed as QString (https://github.com/rinigus/mapbox-gl...l/main.qml#L82), QVariantMap (https://github.com/rinigus/mapbox-gl.../main.qml#L140), and using simpler API for point(s) https://github.com/rinigus/mapbox-gl...apboxgl.h#L166 and lines https://github.com/rinigus/mapbox-gl...apboxgl.h#L172 . Note that adding and updating is the same for QMapboxGL. * Layers are responsible for rendering sources and can be added/removed. See https://www.mapbox.com/mapbox-gl-js/style-spec/#layers for available properties. As you could see, layers customization is rather extensive and I am not planning to write any crippled API for it. It seems to be simple API already and allows the required flexibility. Let's use it as it is. * Examples for route rendering at https://github.com/rinigus/mapbox-gl.../main.qml#L122 ; current location at https://github.com/rinigus/mapbox-gl.../main.qml#L138 ; points at https://github.com/rinigus/mapbox-gl.../main.qml#L175 * More examples on how to use image-based markers are at https://github.com/mapbox/mapbox-gl-...indow.cpp#L135 * Via queries, you could ask current scale, whether source exists, and which location does the widget point corresponds to. How to ask is shown at https://github.com/rinigus/mapbox-gl...l/main.qml#L63 with the response at https://github.com/rinigus/mapbox-gl.../main.qml#L218 . * API header at https://github.com/rinigus/mapbox-gl...itemmapboxgl.h With the exception of interactive widgets (to be added), it should cover what was suggested by MartinK. Generation of IDs for sources and layers are responsibility of the caller, but that should be OK. As soon as the support for interacting widgets will be ready, I'll start proper testing of the widget by porting Poor Maps over it (the source I am a bit familiar with). This and the tests by others should show us what is missing and if/what should be changed. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
An API allowing to add widgets to the map and associate it with the position in the widget has been added. In short, you need just to specify which location do you want to track and then follow signals to change widget location on the screen accordingly. Tested on desktop demo app and it worked quite nicely (you can add/remove single location and remove all tracked locations as well). See demo app for details:
Main: https://github.com/rinigus/mapbox-gl...p/qml/main.qml Widget that tracks position, hides when out of the screen, and destroys itself when tracking is removed: https://github.com/rinigus/mapbox-gl...l/location.qml I think that its complete now in the sense that I can start testing it further by porting a proper map application over it and see if I hit some problems. Replies to the questions below: Quote:
QtLocation 5.6 - assuming it will come to SFOS - has three main plugins - HERE, Mapbox, OpenStreetMap (http://doc.qt.io/qt-5.6/qtlocation-index.html). All these plugins use tiled maps. QtLocation 5.9 - introduced the first "vector" plugin in the form of Mapbox GL. Mapbox GL Native (https://github.com/mapbox/mapbox-gl-native) has Qt interface (called platform in their project) that was further integrated into QtLocation by providing corresponding QtQuick components and interfaces with the other QtLocation classes. This API: Based on the bits from QtLocation/Mapbox GL plugin (rendering of the map on QtQuick widget); interface to QMapboxGL that provides Mapbox GL functionality for Qt C++; and my understanding of what's needed from application perspective. This API compiles and runs against Qt 5.6 using QtLocation 5.2 (SFOS) and Qt 5.7 / QtLocation 5.7 (desktop), as far as I tested. So, for people writing map apps, this API allows you to have probably one of the best renderings of the map available now, on any platform. In the background, it will communicate with the vector tile server and keep the cache with the minimal effort from the map application writer. APIs for routes, POIs, and position icons are different. Data structures, for most part, are compatible with the QtPositioning coordinates used to provide points, routes (list of coordinates). For more complicated cases, we can see what's the reasonable approach. Now, I don't know how much would take an effort to port an existing application to such API. In my understanding, it shouldn't be too difficult. However, it maybe that the devil is in the details and I underestimate the task. Hence my idea to port Poor Maps over and see how much time does it take in practice as well as whether we can cover all the cases as exposed by complete map application. Edit: I hope I did reply to all questions / please ask again if I missed anything Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Hello rinigus,
First of all, hats down for the work you did/are doing there ! I can confirm the demo app works really good on Desktop, and it is quite easy to build something around the Qml component in a custom application. Updating a geojson source live seems to work without quirks. I got it working with OSRM when it computes a new route to the latest clicked point. I will need a bit more time in the week to clean this a bit before I start pushing it on GitHub, if other can find inspiration in it. Working with it, I have a couple of minor questions/remarks: * margins have a setter, but are not a "real" property. Is this by design or was it a shortcut ? Having them as properties would allow adding them a "Behavior", to smooth switching from one view to another * when trying to find the coordinates for a pixel on the screen, the answer can only be asynchronously obtained as it goes through internal signal/slots : Code:
connect(n, &QSGMapboxGLTextureNode::replyCoordinateForPixel, this, &QQuickItemMapboxGL::replyCoordinateForPixel, Qt::QueuedConnection);I imagine the reason behind this is that the 2 objects live in different threads ? If so, there is not much that could be done to change it. Thanks again ! |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
If true and we can use raster tiles, it leaves us with J1 and JStore issues. While JStore is political and probably induced by QtLocation version available for us, J1 (and Photon Q) is a technical one that we should be able to look into. I may make a small app to test whether this issue is for some arbitrary OpenGL code as well. Would be easier to debug if we can get crashes with the small codebase. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Re margins: its oversight. I'll fix it tonight Re coordinates/pixel: yes, map renderer lives in rendering thread and we have access through main gui thread. I have access to map object either via update method or via signals. What we can do is to add a tag as an additional argument for query (QVariant). Then, when you get a reply, you'll have the same tag delivered. This should allow you to keep all housekeeping info in that tag and simplify your code. I'll add it later tonight, unless someone has a better idea. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Quote:
Edit: looks like the zoom level depends on the tile size. So, I can get blurry images even when the correct level is loaded. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Zeta, I have added a tag for pixel to location conversion. That should simplify your code.
As for margins, not sure how to make them a property. We have 4 margins in the setter. Should I cover them as RectF? It would make it a bit more convolved for the app writer, but maybe its OK. |
Re: App for vector renderer maps, using OpenGL ES 2.0
Blurry rendering issue has been open at https://github.com/mapbox/mapbox-gl-native/issues/10076 . Similar to an issue reported for JS version of the library about 6 month ago.
|
Re: App for vector renderer maps, using OpenGL ES 2.0
Now the question from my side: how to make it simple to use the developed QML extension?
For C++ - based projects, its all trivial. We could just include corresponding library as a subproject in git and merge with the C++ project build system. As soon as QtLocation is allowed, all these projects are also Harbour-proof. For Python-based map applications (Poor Maps and modRana), situation is not that simple. Its either I have to somehow make QML type available as a library or these applications would have to be converted to C++ in small parts (probably just to register type and define main). I presume that having extra lib requirement would make the application non-Harbour proof. The library has a small chance to be integrated into device either, since its LGPL3 (I used parts of the code from current QtLocation, hence the license). Any ideas? If we go with the library approach, how do I register it in the QML to make it available? PS: Zeta, margins are now a property through QRectF class. |
| All times are GMT. The time now is 20:51. |
vBulletin® Version 3.8.8