QT map widget

Till Harbaum / Lists wrote:
> Hi,
>
> Am Freitag 11 Juni 2010 schrieb Marijn Kruisselbrink:
>> You might also want to look at the marblewidget (http://edu.kde.org/marble/).

>
> I did. On the n900 as well as on the linux desktop. While i really think this
> is great for desktops i also think that it isn't the right thing for mobile
> devices. There are several issues:
>
> - It is big and installs ~10MB data
> - It is pretty complex and doesn't really fit on the small screen
> - It takes several seconds to load
> - It runs pretty slow
<snip>
> I have read that poeple are working on the speed issue. But speed alone isn't

And speedups may be very possible - if for example you can offload
portions of the workload onto a GPU.

But, for the forseeable future, 3D will not always be available on the
mobile platform.

Especially as I wouldn't expect the future of featurephones to be a
simple race to 2GHz/GPU/...

Yes, that'll be happening - but in parallel will be soon coming out (I
predict - regrettably I have no inside info) n900-lite devices based on
whatever can be gotten that week in china.

It's also not impossible that as capacities of cheap phones rise - take
a look at http://noknok.tv/2010/01/04/nokia-5230-officially-shipping/ -
for example - and even phones at the very bottom of the market are
starting to include 'web browsers' - capabilities of the processors and
GPU will not be up to n900 levels for some years.

The ability for such a widget to be 'cross platform' - and run on small
devices would be a valuable one.

Hi Till,

> It is big and installs ~10MB data

For the desktop/edu version we have shipped some offline data so that even without internet connection the user gets a decent global map.

Technically the data is not really needed. You can remove the country flags, the bitmap data (except for tile-0) and as long as you remove vector-based maps from the selection you can also remove the vector data completely. This would basically result in 0 MB of data needed for Marble.

Marble is currently part of the KDE-EDU module. We'd like to move the most basic data, the library itself and the Qt-Only version out of KDE-EDU.

This will result in a reduced data footprint. The thin KDE app with much of the data will remain in KDE-EDU.

> It is pretty complex and doesn't really fit on the small screen

What exactly do you perceive to be complex? All the overlays (Compass, Scalebar, Overview-Map and On-Screen Controls) are plugins. Their size, visibility and theming can be easily adjusted.

Since version 0.10.x Marble has got device profiles: this means that we can change default appearance depending on which device Marble is running. Currently we've only made some initial adjustments for the N900.

> It takes several seconds to load

That depends on the amount of data and the amount of plugins that is loaded.

If you remove all the default placemarks, all the fancy maps, the vector data and all the fancy plugins (like the stars plugin) then you end up with something that is similar to QMapControl in terms of feature set. And you end up with better startup-times.

- It runs pretty slow

Yes, out of the box that's true. Bottlenecks for the performance are:

* Texturemapping. This is done in software using a generic graphics pipeline which is capable to deal with all kind of projections. There are two ways to improve performance:

- Compared to e.g. Ovi Maps we basically "oversample" our textures. Especially on a display that has got a very high resolution like the Nokia devices (about 260 dpi ...) this doesn't make sense.
By displaying/sampling the textures at twice the size we get much better speed and more easily readable streetnames for e.g. OSM.

- As a second solution we'd like to implement a second render option for tiles in Marble's 2D mode. This would basically implement the "2D-QScrollArea" approach that QMapControl and webmaps are taking.
I estimate the amount of development work would be around 2 man weeks.

* Placemark loading/rendering. We load about 20000 placemarks at startup. Loading these is quite slow (I think due to use of the Interview framework). Rendering them at higher zoom levels is also quite slow (due to the fact that we loop through all available placemarks for each frame we render). Solution is to either remove the default placemarks or reduce the amount. Or to

* Reducing the node density for the vector graphics: Compared to e.g. Ovi Maps Marble's vector polylines have a much higher node count per area. This is something that can trivially be reduced for the small screen profile.

So basically it's possible to improve Marble's performance drastically. This is true for 3D as well as 2D.
I've done a bit of testing of prototype implementations on the N900 as well as on other Nokia hardware.
For 2D with all kinds of optimizations we'd have a speed that would be comparable to scrolling an image or a website. For 3D it would be about the same speed (or a bit faster) than what OviMaps does.

I got two things I forgot to mention in my last email:

> we render). Solution is to either remove
> the default placemarks or reduce the amount.
> Or to
>

I accidently stopped my sentence there It should have read:

Solution is to either remove the default placemarks or to reduce the amount of default placemarks. Or to cycle only through those placemarks which are visible (based on a BSP
approach similar to the one we are taking for
the tiles already.

> For 2D with all kinds of optimizations we'd have a speed that would be comparable to scrolling an image or a website. For 3D it would be about the same speed (or a bit faster) than what OviMaps does.
>

The second sentence should have read:

For 3D it would be about the same speed (or a bit faster) than what OviMaps does in its 3D mode.

Hi,

Am Samstag 12 Juni 2010 schrieb Ian Stirling:
> And speedups may be very possible - if for example you can offload
> portions of the workload onto a GPU.
That addresses the performance problem, but this likely also if you do this
for performance reasons, it also increases battery consumption as you
put additional load onto another component of the SOC. But it may still be
good to offload certain tasks from the main CPU to the GPU as the GPU
may do the same thing more power efficient.

I really think low battery consumption is the most important issue with
a map widget as this type of widget is meant to be used over a longer
period of time and while being away from stationary power.

Till

[Till Harbaum / Lists Sa 12. Juni 2010]:
> Hi,
>
> Am Samstag 12 Juni 2010 schrieb Ian Stirling:
> > And speedups may be very possible - if for example you can offload
> > portions of the workload onto a GPU.
> That addresses the performance problem, but this likely also if you do this
> for performance reasons, it also increases battery consumption as you
> put additional load onto another component of the SOC.

It's rather moot, as this isn't a movie at 25fps, so an occasional image
refresh, no matter how it's done, will take magnitudes less energy per time in
average, than the backlight eats to display the image. When screen is dimmed
(or the widget invisible/hidden/background) then of course all gfx workload
should suspend, for obvious reasons

/j

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkwT30wACgkQ7Xtwhpk1Ugz46ACgkADf7TptPjS3le78/ZkQ0XSS
VrQAn0MQgdhwx3weyVFpvqcfEW8+08Ij
=sENg
-----END PGP SIGNATURE-----

Hi,

Am Samstag 12 Juni 2010 schrieb Joerg Reisenweber:
> It's rather moot, as this isn't a movie at 25fps, so an occasional image
> refresh, no matter how it's done, will take magnitudes less energy per time in
> average, than the backlight eats to display the image. When screen is dimmed
> (or the widget invisible/hidden/background) then of course all gfx workload
> should suspend, for obvious reasons

100% CPU load is bad no matter if this is for a 25fps movie or a 0.5fps 3d map
widget. Believe me, i have these discussions regarding maep. People _do_ care
for CPU load and battery consumption. And this is good.

Till

Hey

When I started to write eCoach in Qt I had to search for existing
mapwidget in Qt. I came to result that QMapControl is the best current
solution. I tried also marble but i think it is an overkill for a device
like N900.

I suggest that the QMapControl could be the basis for the new Qt mapwidget.
I have contacted the original author of the widget but he seems to be
not so interested maintaining/developing the widget anymore.

Current issues i noticed with the QMapControl on Maemo:

- Slow tile rendering and panning
- Tile caching makes it even slower
- No good way to draw route on realtime
- Google maps not working

I dont think that we need to write whole thing from the scratch, mostly
QMapControl needs only optimization and of course better solution for
live route drawing.

- There is also support for common maptile servers and for example
support for finnish topomaps should work out of the box with existing
OSM maptile plugin if the funny authentication for topomaps server will
be implemented.

//Sampo

Hi,

> 100% CPU load is bad no matter if this is
> for a 25fps movie or a 0.5fps 3d map
> widget. Believe me, i have these
> discussions regarding maep. People _do_ care
> for CPU load and battery consumption.
> And this is good.

Right. The amount of CPU load used by Marble depends on the map quality that you set (You can choose between Print, High, Normal and Low). And it depends on the QGraphicsSystem being used.

Of course CPU load when nothing happens is basically 0%.

Once you navigate it might easily go to 100% due to the fact that the current render is scanline based.

If we implement the scrollarea render solution for Marble then the CPU load used will be comparable to what you get when you scroll a website or image (or what you get for QMapControl). Again as I said we are talking about maybe 2 man weeks. That's *slightly* less than what it takes to implement all the stuff that is missing in QMapControl.

Hi,

> When I started to write eCoach in Qt I had to search for existing
> mapwidget in Qt. I came to result that QMapControl is the best current
> solution. I tried also marble but i think it is an overkill for a device
> like N900.

So QMapControl fits your personal needs. That's cool.
There is enough room to have two great map widgets for Maemo that developers can choose from. That's the beauty of Free Software and Open Source.

In fact neither Marble nor QMapControl will go away.

> - Slow tile rendering and panning

Just curious: What framerate do you want to achieve as a minimum on a device like the N900 when doing panning? :-)

> - Tile caching makes it even slower
> - No good way to draw route on realtime
> - Google maps not working

These issues don't exist in Marble. :-)

> I dont think that we need to write whole thing from the scratch, mostly
> QMapControl needs only optimization and of course better solution for
> live route drawing.

And I guess it also needs:

* routing
* a position provider
* building up an active development community behind the widget (you know, people who feel responsible for bugs and implementation of new features)

and probably lots of other stuff that will be requested by developers. Stuff that is likely already there in Marble. :-)

Till Harbaum / Lists wrote:
> Hi,
>
> Am Samstag 12 Juni 2010 schrieb Joerg Reisenweber:
>> It's rather moot, as this isn't a movie at 25fps, so an occasional image
>> refresh, no matter how it's done, will take magnitudes less energy per time in
>> average, than the backlight eats to display the image. When screen is dimmed
>> (or the widget invisible/hidden/background) then of course all gfx workload
>> should suspend, for obvious reasons
>
> 100% CPU load is bad no matter if this is for a 25fps movie or a 0.5fps 3d map
> widget. Believe me, i have these discussions regarding maep. People _do_ care
> for CPU load and battery consumption. And this is good.

I believe the point is not that battery life is unimportant, but that
with the backlight on, the CPU using 200% of nominal for 2/25th of the
time, this increases the total CPU power by 8%.

But - using numbers from
http://wiki.maemo.org/N900_Hardware_Power_Consumption - with the screen
on dim, and the GPS on, this 8% drops to 4% of total system load. - with
the backlight on bright, it's only an increase of 2.5% or so.

The main point I was attempting to make was not this one anyway.

It was that while 3D may be possible on platforms similar to the n900,
it is undesirable, even if it performs perfectly, if the widget may also
be wanted to run on the increasing number of low end phones that may
have limited or no 3D capability.

(Unless of course it can also do 2D optimally - but that seems like lots
more code/work.)