Plans for Qt support

[ntadej]

Does this fork also plan to support Qt?

[petr-pokorny-1]

Unfortunately, we dont have any Qt developer in the team currently. Any help from the community would be great!

[rinigus]

We have one PR submitted to Mapbox GL Native for improving building support for Qt backend (addition make install). I guess, we could submit the same over here as well.

As for Qt support, please keep it. Not sure how much I could contribute myself, let's see.

[kiibimees]

@ntadej , I see that you have submitted CMake changes for Qt6. I have been working on porting QtLocation to Qt6. Majority of the work is already done. Mapbox GL plugin was still missing and I tried to replace it with Maplibre but having some issues rendering the map. I'm also a bit stuck and in need of a little help.

[ntadej]

The issue with MapLibre at the moment is that for some reason it always renders in the back, but I'm not a GL expert to be able to find out why. Here is my plugin fork that works for me on all platforms (that I tested): https://github.com/ntadej/qt-geoservices-maplibre

[rinigus]

@ntadej: have you tried to bisect and see where the change in rendering was introduced? Or was it there in Mapbox GL Native already?

[ntadej]

No, not really. The problem is the Qt MapBox GL plugin was stuck on a VERY old version. Also they moved some files around for their build so it's more or less impossible to find the point in time when it broke. I asked at the MapLibre Slack channel for ideas but all the obvious checks did not yield any clear outcome. Then I just decided to use transparent main QML Item in my app and it solved the issue (but I have yet to see if there are any performance implications) 😊

[rinigus]

I will test Maplibre against alternative QML plugin (https://github.com/rinigus/mapbox-gl-qml) and let's see if the same issue will occur. As that plugin works with the latest Mapbox GL Native, it should be easier to bisect if needed.

[kiibimees]

Nevemind, gentelmen, I got it working! @ntadej , you plugin is based on Qt 5 but I was having troubles on Qt 6.

Now, if you take this:
https://codereview.qt-project.org/c/qt/qtlocation/+/382087

It is currently the latest commit on the bigger work to port QtLocation to Qt 6. It compiles with Windows/MinGW and shows vector tiles. MSVC needs a few changes about boost and exceptions and CMake INSTALL target, but should work as well.

[ntadej]

MSVC works for me in Qt5 though. I never updated the plugin to Qt6 as the infrastructure was not there.

[kiibimees]

MSVC works for me in Qt5 though. I never updated the plugin to Qt6 as the infrastructure was not there.

Yes, of course. Now luckily it's almost ready. And I used MSVC 2019 since this is the officially suported version for Qt 6. Next week I will try MSVC build again and have a fresh look at the issues.

[ntadej]

I have a Qt5-based MSVC 2019 CI running here if interested: https://github.com/ntadej/qt-geoservices-maplibre/actions/workflows/CI-Windows.yml

[kiibimees]

I have a Qt5-based MSVC 2019 CI running here if interested: https://github.com/ntadej/qt-geoservices-maplibre/actions/workflows/CI-Windows.yml

Thank you! I will definitely have a look at it next week. I didn't know that you have made so many things already.

[kiibimees]

Now, when building with MSVC 2019 and Qt 6, I have to apply two things.

1. Set the same exception handling compiler flag as Qt 6 does:

if(MSVC)
    target_compile_options(mbgl-core PUBLIC "/EHsc")
endif()

2. And apply Boost bug fix (strange that it works in your CI):
   boostorg/proto@c0e9b4d

[kiibimees]

@ntadej , I renamed the old MapboxGL plugin and made a push to Qt Gerrit but now we reach the point where we could cooperate. Maplibre itselt is in the need of Boost library upgrade. Style handling and short URI cheme needs handling, to be able to switch between different servers, and so on. What are your plans?

[rinigus]

As there is discussion regarding cmake, I wonder if someone from here can review #192 .

[srcejon]

I have a Qt5-based MSVC 2019 CI running here if interested: https://github.com/ntadej/qt-geoservices-maplibre/actions/workflows/CI-Windows.yml

Thanks. I've just given it a try and while it works, it seems to be very slow at drawing the maps (Compared to mbgl-qt.exe, for example). I'd noticed the same when I did my build for #192.

Is this something you see as well? Any ideas what the problem might be?

[ntadej]

I have a Qt5-based MSVC 2019 CI running here if interested: https://github.com/ntadej/qt-geoservices-maplibre/actions/workflows/CI-Windows.yml

Thanks. I've just given it a try and while it works, it seems to be very slow at drawing the maps (Compared to mbgl-qt.exe, for example). I'd noticed the same when I did my build for #192.

Is this something you see as well? Any ideas what the problem might be?

Do you mean the QML plugin? I did not do many tests on Windows yet (and I only use a virtual machine) so I could not compare pure GL mode and the QML mode. I know there are some layering issues with QML that may affect performance, but I do not know enough of GL or MapLibre internals to fix it.

[ntadej]

Hi @kiibimees, yes it's unfortunate that boost update seems to be needed in some cases (although for me it works both in the CI and in a Windows virtual machine). Maybe it's related to Qt 6 and its compiler flags.

Regarding the configuration. As this will be considered a new plugin, I guess we could break it and define new configuration API for it to be able to toggle different configuration schemas.

I read the Gerrit changeset quickly and I wonder if having the plugin decoupled from the Qt releases might actually be a good idea so it does not have to tightly follow the Qt release cycle. This probably means less support from the core Qt team but I'm under impression that mapping is not the top priority for you/them anyways.

Please note that I'm working on this sporadically and only in my free time so I certainly do not represent the MapLibre goals. Maybe @petr-pokorny-1 could comment if he has a better opinion on how Qt support in MapLibre should be handled.

[srcejon]

Thanks. I've just given it a try and while it works, it seems to be very slow at drawing the maps (Compared to mbgl-qt.exe, for example). I'd noticed the same when I did my build for #192.
Is this something you see as well? Any ideas what the problem might be?

Do you mean the QML plugin? I did not do many tests on Windows yet (and I only use a virtual machine) so I could not compare pure GL mode and the QML mode. I know there are some layering issues with QML that may affect performance, but I do not know enough of GL or MapLibre internals to fix it.

Yes, within QML. Me neither!

[kiibimees]

I read the Gerrit changeset quickly and I wonder if having the plugin decoupled from the Qt releases might actually be a good idea so it does not have to tightly follow the Qt release cycle. This probably means less support from the core Qt team but I'm under impression that mapping is not the top priority for you/them anyways.

Yeah, I wonder. Using the plugin as part of QtLocation is so much easier than including third party libs. Unfortunately it might happen that it will never be included in the Qt release, or worse, QtLocation will never be released. But it would be so nice if one could just clone'n'compile QtLocation from source and have everything included. That's why I was aiming to integrate it into Qt codebase.

Regarding the configuration. As this will be considered a new plugin, I guess we could break it and define new configuration API for it to be able to toggle different configuration schemas.

Yes, I agree. @ntadej, if you are not planning any activities in the near future, I can start doing it myself.

[ntadej]

No, I do not plan to do anything in the near future as I use absolute URLs in my app which just work. Feel free to tag me on Gerrit though if you want, I have an account there (I still have some mapbox Qt5 change sets open which I should probably close once they are integrated in the maplibre plugin).

[rinigus]

As a remark - while using https://github.com/rinigus/mapbox-gl-qml built against MapLibre (maplibre branch of that plugin), I don't see any degradation in performance on Linux PC nor Sailfish OS on phone. It could use different layering than the official one, though. Haven't tested on Windows and cannot do it either.

[kiibimees]

Windows MSVC debug build has a pretty bad performance. Release or RelWithDebug is nice and smooth.

[srcejon]

Yep, I was using a release build. The standalone demo app is OK, so I suspect it's something to do with QML.

[raphaelscholle]

Any news on that "issue" ?
I'm having a rough time to upgrade our Project "OpenHD", just because of moving to bullseye and geoservices_mapboxgl not being free anymore.

[ntadej]

We are almost there to have full plugin support both in Qt5 and Qt6 (note that Qt6 still has some limitations).

[raphaelscholle]

That sounds really nice I would love to implement this into our software (OpenHD)

[mdehollander]

We are almost there to have full plugin support both in Qt5 and Qt6 (note that Qt6 still has some limitations).

Super! Can I ask what full support means? Does this include all features from the Android/iOS SDK? I would be specifically interested in the offline manager described in the android sdk api and original mapbox docs

[ntadej]

Not from the start. Qt SDK is at the moment just a very thin layer on top. Also I as the main developer do not need this functionality. If there is a working example it should probably not be hard to port though.

[ntadej]

The first release has been published (with QML plugin following soon after). I propose we close this ticket in favour of dedicated ones for specific feature requests.

See https://github.com/maplibre/maplibre-gl-native/releases/tag/qt-v2.0.0