Commit e2091b15 authored by Torsten Rahn's avatar Torsten Rahn
Browse files

This commit brings performance on my tablet from 3fps to about

30 fps at level 17:

However this is just a workaround for the real problem:

The Routing element is _another_ 99% fullscreen QQuickPaintedItem
which by default created and painted onto a QImage, then uploaded
to the GPU for every single frame and blended semitransparently
over the maps QQuickPaintedItem --- even if the Routing element
showed nothing (and the huge QImage was fully transparent)!

The better solution would be to turn the Routing element into
a real QQuickItem and only make it visible when there is a
route available (the hasRoute property seems to only get
updated as expected when the item is visible, so at the
moment it's not possible to bind the visibility to this property.
For this reason I've bound the visibility to the routeEditor
visibility instead - which is yet another bad workaround).

The implementation of a well-behaving Routing element would be
trivial using GeoPainter::polygonFromLineString and would
sort out the remaining slowness while a route is displayed.
parent 1dbc21b5
......@@ -119,6 +119,7 @@ ApplicationWindow {
anchors.fill: parent
marbleItem: marbleMaps
routingProfile: routeEditor.routingProfile
visible: routeEditor.visible
PositionMarker {
......@@ -58,6 +58,7 @@ RoutingPrivate::RoutingPrivate(QObject *parent) :
Routing::Routing( QQuickItem *parent) :
QQuickPaintedItem( parent ), d( new RoutingPrivate(this) )
connect(d->m_routeRequestModel, SIGNAL(rowsInserted(QModelIndex,int,int)), this, SLOT(updateWaypointItems()));
connect(d->m_routeRequestModel, SIGNAL(rowsMoved(QModelIndex,int,int,QModelIndex,int)), this, SLOT(updateWaypointItems()));
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment