Re: QT map widget
kate.alh...@nokia.com wrote: Situation is when lot of map tiles are loaded. loaded as in downloaded? About the number of tiles loaded into memory, mappero uses a tile cache, which is actually quite big (140 tiles, and tiles are textures sized 256x256 pixels) so it may consume quite a bit of memory. But in my case, according to top the RSS is about 21MB, which doesn't seem so scary. I dont't know what internaly happens. Some memory leak ? For application performance and cpu usage also time needed for tile pre-processing need to be counted. I doubt there are any substantial memory leaks, I've been using mappero for several hours without breaks, and didn't notice any worsening. Does it some scaling for tiles after loading them ? No, it does only if the tile of the needed size is missing. But that's something you can notice quite easily, because it's quite evident when the pixels are being doubled. Finally time used for scaling tiles is one key issues. Do we scale them or download every size. How much cpu power is used for scaling or do we leave it all for GPU ? Every size is downloaded. Scaling happens rarely, and it is done on the CPU; but after scaling the texture is stored into the GPU and reused, so the performance hit is minimal. For mappero case i don't know how much cpu is used for actual scaling and how much by exhausting virtual memory ? I'm not sure about virtual memory, but about CPU mappero will never use more than 30-35% -- it simply isn't allowed by the OS (startup times could be much faster if it were...). Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Dnia 2010-06-13, nie o godzinie 14:39 +0300, Alberto Mardegan pisze: (off topic: if you can find some way to reproduce it reliably, please file a bug -- although if you really need to take out the battery, that cannot be a bug in the application itself) I had similar problem and even filled a bug: https://bugs.maemo.org/show_bug.cgi?id=9743 Could not reproduce it with PR1.2 so closed it. If you want to you can reopen it - I will gladly test some use cases. Regards. -- Tomasz Rybak bogom...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
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.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
- Original message - kate.alh...@nokia.commailto:kate.alh...@nokia.com wrote: I don't know hat mappero (ex maemo mapper) does internaly but least, it can eat all cpu power when doing processing maps so that only way out is remove battery from device. I've been told that this happens when downloading large amounts of map tiles, so it has nothing to do with the map widget itself. That one is based on clutter, and seems to be quite efficient. Situation is when lot of map tiles are loaded. I dont't know what internaly happens. Some memory leak ? For application performance and cpu usage also time needed for tile pre-processing need to be counted. Does it some scaling for tiles after loading them ? Finally time used for scaling tiles is one key issues. Do we scale them or download every size. How much cpu power is used for scaling or do we leave it all for GPU ? For mappero case i don't know how much cpu is used for actual scaling and how much by exhausting virtual memory ? (off topic: if you can find some way to reproduce it reliably, please file a bug -- although if you really need to take out the battery, that cannot be a bug in the application itself) I think, without any actual debug or analysis that it consumes all virtual memory and there won't be any memory for system UI even kill application when everything is swapped out. Kate Ciao, Alberto -- http://blog.mardy.it -- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb Marijn Kruisselbrink: You might also want to look at the marblewidget (http://edu.kde.org/marble/). As far as I know it can be built without any kde dependency, and is pretty powerful. 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 I do understand why people like it, really. But i think the latter two issues are show stoppers. People just won't accept that adding simple map to their programs will cause it to run slow. I have read that poeple are working on the speed issue. But speed alone isn't the problem. More important is battery consumption as those apps tend to be used for a longer period of time. And you wouldn't just have to make it run fast, you'd have to make it run fast without imposing a significant CPU load. Thus i think this whole 3D approach, as cool as it is, doesn't suit the mobile world. All the trigonometrics involved in 3D and the additional CPU load required for proper image stretching/scaling imho doesn't justify the battery drain this will cause. Or am i mistaken and the Marble widget can be switched into some fast and low-CPU 2D mode? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 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. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
[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 signature.asc Description: This is a digitally signed message part. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: QT map widget
-Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of ext Till Harbaum Sent: 11 June, 2010 12:03 To: maemo-developers@maemo.org Subject: QT map widget Hi, with the switch to qt i think there's a need for a qt map widget. I really see a need for a unified widget to be used by all applications. The current situation with multiple different map widgets on maemo5 shows what imho should be prevented: - They store cached tiles at different locations wasting bandwidth as well as device flash space - No central point for map maintenance (e.g. cleaning the map cache or downloading entire areas into the cache for offline usage) - No easy and central way to add new map sources - The overall look and feel is different although they intend to provide similar function - Some widgets work behind network proxies, some don't - None of these widgets is really developer friendly I agree with those. Sampo Savola, the author of ecoach suggested to think about a qt map widget. I am also interested in this as i am the author of osm2go, maep and gpxview. Who else would like to contribute to this? I'd like to make sure that such a widget satisfies most developers need to be able to address above issues with one single qt map widget. It looks like the people at Qt are thinking of this as well. http://qt.nokia.com/developer/qt-roadmap/ mentions Maps/Navigation API and while the details are really scarce (it's only a roadmap, so that is expected), it does state that: Provides an API to access maps, landmarks and route information for navigation. Now just to find some troll from Qt who could open that up a bit. Tero A start may be this widget: http://medieninf.de/qmapcontrol/ Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
On Friday 11 June 2010 11:02:53 Till Harbaum wrote: Hi, with the switch to qt i think there's a need for a qt map widget. I really see a need for a unified widget to be used by all applications. The current situation with multiple different map widgets on maemo5 shows what imho should be prevented: - They store cached tiles at different locations wasting bandwidth as well as device flash space - No central point for map maintenance (e.g. cleaning the map cache or downloading entire areas into the cache for offline usage) - No easy and central way to add new map sources - The overall look and feel is different although they intend to provide similar function - Some widgets work behind network proxies, some don't - None of these widgets is really developer friendly Sampo Savola, the author of ecoach suggested to think about a qt map widget. I am also interested in this as i am the author of osm2go, maep and gpxview. Who else would like to contribute to this? I'd like to make sure that such a widget satisfies most developers need to be able to address above issues with one single qt map widget. A start may be this widget: http://medieninf.de/qmapcontrol/ You might also want to look at the marblewidget (http://edu.kde.org/marble/). As far as I know it can be built without any kde dependency, and is pretty powerful. Marijn ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
A start may be this widget: http://medieninf.de/qmapcontrol/ You might also want to look at the marblewidget (http://edu.kde.org/marble/). As far as I know it can be built without any kde dependency, and is pretty powerful. Apparently it's also already running on an N900 (from the bottom of the linked page, just in case anyone missed it): http://nienhueser.de/blog/?p=95 https://garage.maemo.org/projects/marble Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Till, I totally agree! regarding qmapcontrol, i was just talking to sampo about this and we identified a rendering bug that i fixed in place (hes got the latest code somewhere) i like the look of this widget, its fairly simple to understand and has support for multiple download services and would make an excellent base to build from. Gary /me makes note to file the related qt bug about the polygon rendering error we identified. On Fri, Jun 11, 2010 at 9:50 AM, Simon Pickering s.g.picker...@bath.ac.ukwrote: A start may be this widget: http://medieninf.de/qmapcontrol/ You might also want to look at the marblewidget ( http://edu.kde.org/marble/). As far as I know it can be built without any kde dependency, and is pretty powerful. Apparently it's also already running on an N900 (from the bottom of the linked page, just in case anyone missed it): http://nienhueser.de/blog/?p=95 https://garage.maemo.org/projects/marble Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
On 11/06/2010 10:02, Till Harbaum wrote: with the switch to qt i think there's a need for a qt map widget. I really see a need for a unified widget to be used by all applications. The current situation with multiple different map widgets on maemo5 shows what imho should be prevented: - They store cached tiles at different locations wasting bandwidth as well as device flash space - No central point for map maintenance (e.g. cleaning the map cache or downloading entire areas into the cache for offline usage) - No easy and central way to add new map sources - The overall look and feel is different although they intend to provide similar function - Some widgets work behind network proxies, some don't - None of these widgets is really developer friendly I should add that I totally agree with the goal here. The question is whether it would be better to decide exactly what we want (in terms of features, hw accelerated rendering, etc.) and write something new, or to modify an existing piece of code. Certainly if this qmapcontrol is suitable that would make life easier (and from a quick glance it looks ok). Would a wiki page be useful to determine people's wishes for such a widget? Just thinking off the top of my head there are things like: Multiple map sources. Would that include things that are available but not necessarily fully legal e.g. Google maps - at least it should provide a way for third parties or users to enable such things? What about deciding what sorts of local POI lookups, routing, traffic info, etc. might be wanted, and whether it should/can come from online or local vector map data (e.g. OSM), or even RDS ;) and how these should be provided. Overlays are another important point - this was a stumbling block for Maemo-mapper for a long time iirc. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: QT map widget
Hi, - original Nachricht I should add that I totally agree with the goal here. The question is whether it would be better to decide exactly what we want (in terms of features, hw accelerated rendering, etc.) and write something new, or to modify an existing piece of code. Exactly that's why i am asking here instead of just start coding like i did with maep. That approach wasn't successful. Would a wiki page be useful to determine people's wishes for such a widget? Just thinking off the top of my head there are things like: Sure. But there's one thing we really need to make sure: We need to prevent this from becoming one of those projects that are discussed in every detail without anyone actually doing some work. So perhaps a wiki page make sense, sure. But a garage project with mailing list may be more suitable to keep people interested. Multiple map sources. Would that include things that are available but not necessarily fully legal e.g. Google maps - at least it should provide a way for third parties or users to enable such things? I get frequent requests for user configurable map sources for maep. There are e.g. nice topo maps for finland. Integrating these into the main branch imho doesn't make much sense as these are only interesting for people in finland. I propose some xonfiguration scheme that can be extended just by downloading additional config files from the repositories. Installing finland topo maps would then enable those maps in all apps using this widget. What about deciding what sorts of local POI lookups, routing, traffic info, etc. might be wanted, and whether it should/can come from online or local vector map data (e.g. OSM), or even RDS ;) and how these should be provided. It sure has to be discussed what the widget will provide by itself. These are technical things like GPS integration as well as features like track and waypoint support. I'd say: Technical support for these very common items should be there as e.g. nearly all apps will want to draw something onto the map. It's still to be discussed if even specific waypoint sources should be included into the main map widget. E.g. why should a user be bothered with speed cams in a program displaying bell towers on a map? On the other hand, any program displaying places is intended to be used to get to those places, so navigation may make sense. Also support for very different map types like pre-rendered tiles as well as vector maps sounds great. The finish topo maps would then be a config option for the tile based map renderer. Overlays are another important point - this was a stumbling block for Maemo-mapper for a long time iirc. Yes, overlays are very important, even the option for arbitrary ones as you probably won't be able to predict all use cases. I e.g. always wanted to be able to overlay semi-transparent altitude-maps as this would e.g. give some 3d like effect even for google maps. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb tero.k...@nokia.com: It looks like the people at Qt are thinking of this as well. http://qt.nokia.com/developer/qt-roadmap/ mentions Maps/Navigation API and while the details are really scarce (it's only a roadmap, so that is expected), it does state that: Provides an API to access maps, landmarks and route information for navigation. This also sounds like the wouldn't mind community input/cooperation. Now just to find some troll from Qt who could open that up a bit. Maybe someone inside Nokia could approach them ... hint, hint ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Hi, Am Freitag 11 Juni 2010 schrieb Simon Pickering: Would a wiki page be useful to determine people's wishes for such a Here we go: http://wiki.maemo.org/QTMapWidget Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
