This object is in archive!
Finer zoom levels option
Completed
Sometimes - usually when I`m zooming beyond the last zoom/tile level to see more detail, the jump between zoom levels (100% to 200% to 300% for example) is too big, and I want something in-between. I can get that by doing a `pinch-zoom`. but that requires me to keep my fingers steady on the screen while trying to read the map
Would it be possible to have a selectable option for `fine-zooming`, when zoom lock is on. So it could zoom from 100% to 150% to 200% to 300% to 400% instead of 100% to 200% to 400%
Obviously a `smooth zoom` (like you get pinch-zooming, but also as you hold down the zoom buttons, and stays at that level when you release the button) would be even better, but might be a bit overkill.
I like this idea 
In my opinion, pinch zoom should NEVER snap to those 1,2,3,4,...20 etc zoom levels. Locus should leave the map position & size exactly as it is when fingers are removed, ie "inbetween" two levels.
Why? When you zoom with two fingers, you basically grab two distinct points on the map and move them around. They more or less stick to your two fingers. It is highly irritating when Locus snaps to a different zoom after you remove your fingers. Your eyes lose focus and you have to concentrate anew on what you were looking at.
Obviously, when you zoom with plus/minus buttons or doubletap (googlemode), snapping to levels is just fine. Of course some sort of animated soft zooming would be nice to have here, but thats a different story which probably has to wait until a Locus-MapEngine-OpenGL-Rewrite.
In my opinion, pinch zoom should NEVER snap to those 1,2,3,4,...20 etc zoom levels. Locus should leave the map position & size exactly as it is when fingers are removed, ie "inbetween" two levels.
Why? When you zoom with two fingers, you basically grab two distinct points on the map and move them around. They more or less stick to your two fingers. It is highly irritating when Locus snaps to a different zoom after you remove your fingers. Your eyes lose focus and you have to concentrate anew on what you were looking at.
Obviously, when you zoom with plus/minus buttons or doubletap (googlemode), snapping to levels is just fine. Of course some sort of animated soft zooming would be nice to have here, but thats a different story which probably has to wait until a Locus-MapEngine-OpenGL-Rewrite.
I absolutely agree with this idea. It quite often happens to me that I don`t get the required area on the screen if zoom level is too high or loose major parts of the display for an area which is much too wide for what I`d like to see if I choose one zoom level lower.
Exactly this problem can be solved by pinch to zoom and is anyway already implemented.
I absolutely agree with this idea. It quite often happens to me that I don`t get the required area on the screen if zoom level is too high or loose major parts of the display for an area which is much too wide for what I`d like to see if I choose one zoom level lower.
Exactly this problem can be solved by pinch to zoom and is anyway already implemented.
Yes - pinch zoom is always a bit hit-and-miss with me. Sometimes it stays as it is, sometimes it snaps - not sure what the rules are for when it happens...
If pinch zoom stayed as it is, then I see no need for the finer zoom levels I suggested above - I`d just know to use pinch zoom instead.
Yes - pinch zoom is always a bit hit-and-miss with me. Sometimes it stays as it is, sometimes it snaps - not sure what the rules are for when it happens...
If pinch zoom stayed as it is, then I see no need for the finer zoom levels I suggested above - I`d just know to use pinch zoom instead.
I cannot completely agree with this ...
it have two main disadvantages:
1. map draw in other then 100% scale is always - worst. Even if anti-alising is applied, map have to be rescaled so image quality is worst and I`m more then sure, that some people will want some settings to disable this "feature"
2. when you display map in less then 100%, there is always need more images to cover screen. It brings more loading from card, more CPU usage to decompressing, more memory etc etc ... and empty battery and more crashes on OutOfMemory
when you have map with zoom 12 and 13, then by you when you zoom by fingers and will be closer to 13, Locus will use level 13 reduced to 50%? This map takes twice time to load, is unreadable because everything is twice as small etc ...
To Skids: snapping behaviour is simple. When you zoom by fingers and zoom-lock is not active, then Locus compute best zoom to display. If zoom-lock is active (blue highlight of bottom icon) and there is no specific zoom values and you can zoom with fingers as you want.
In Locus it`s not so "simple" as in GMAPS for example. There are maps rendered from vector data so there is no problem with blurred images or huge number of tiles ...
I cannot completely agree with this ...
it have two main disadvantages:
1. map draw in other then 100% scale is always - worst. Even if anti-alising is applied, map have to be rescaled so image quality is worst and I`m more then sure, that some people will want some settings to disable this "feature"
2. when you display map in less then 100%, there is always need more images to cover screen. It brings more loading from card, more CPU usage to decompressing, more memory etc etc ... and empty battery and more crashes on OutOfMemory
when you have map with zoom 12 and 13, then by you when you zoom by fingers and will be closer to 13, Locus will use level 13 reduced to 50%? This map takes twice time to load, is unreadable because everything is twice as small etc ...
To Skids: snapping behaviour is simple. When you zoom by fingers and zoom-lock is not active, then Locus compute best zoom to display. If zoom-lock is active (blue highlight of bottom icon) and there is no specific zoom values and you can zoom with fingers as you want.
In Locus it`s not so "simple" as in GMAPS for example. There are maps rendered from vector data so there is no problem with blurred images or huge number of tiles ...
Of course it`s "worse" and "slower" when you scale. A properly antialiased scale is not THAT bad though. It is also not THAT slow on modern hardware. All in all, it is still much better than wildly jumping around to other zoom levels and making the eyes lose focus. Frankly, I know no other app on Android that does not stay where you put it when using pinch zoom. It is simply what people have come to expect on mobile devices. Of course it is "harder to handle" for Locus compared to a simple picture viewer, but that it is only a problem for you and shouldnt concern your users :-).
As to what zoom level to use as base for scaling... it remains to be seen if that should always be
the next smaller one scaled larger
or the next bigger one scaled smaller
or the closest one scaled larger/smaller (i like that)
As for the option to "disable" this feature... in my opinion that is not neccessary. You can always "disable" it and get to the next proper level by using the zoom buttons or twofinger-tap/double-tap instead. But well, create one by all means: "Snap to 100% levels when pinch zooming" yes/no
GMAPS even pinchzooms nicely when you add raster tile layers like sat images or terrain btw... i know... they blur better than raster map data... but still :)
btw... i also think that twofinger-tap/double-tap for zoom-in/zoom-out should be the default and no other setting should be offered. it is googlemaps, it is standard, it is good, it is what people expect. other prefs options (like hide/show menus on doubletap) only add confusion. of course some long-term-locus-users might complain at first. but in the long run, we will all benefit from apps that behave predictable and similar to each other.
Of course it`s "worse" and "slower" when you scale. A properly antialiased scale is not THAT bad though. It is also not THAT slow on modern hardware. All in all, it is still much better than wildly jumping around to other zoom levels and making the eyes lose focus. Frankly, I know no other app on Android that does not stay where you put it when using pinch zoom. It is simply what people have come to expect on mobile devices. Of course it is "harder to handle" for Locus compared to a simple picture viewer, but that it is only a problem for you and shouldnt concern your users :-).
As to what zoom level to use as base for scaling... it remains to be seen if that should always be
the next smaller one scaled larger
or the next bigger one scaled smaller
or the closest one scaled larger/smaller (i like that)
As for the option to "disable" this feature... in my opinion that is not neccessary. You can always "disable" it and get to the next proper level by using the zoom buttons or twofinger-tap/double-tap instead. But well, create one by all means: "Snap to 100% levels when pinch zooming" yes/no
GMAPS even pinchzooms nicely when you add raster tile layers like sat images or terrain btw... i know... they blur better than raster map data... but still :)
btw... i also think that twofinger-tap/double-tap for zoom-in/zoom-out should be the default and no other setting should be offered. it is googlemaps, it is standard, it is good, it is what people expect. other prefs options (like hide/show menus on doubletap) only add confusion. of course some long-term-locus-users might complain at first. but in the long run, we will all benefit from apps that behave predictable and similar to each other.
Thankyou - I`ve had a play around and now I understand how the snapping work. I tend to use +/- volume for zooming and haven`t used finger zoom very much - I shall have to start using it more.
However - this means I have another request (sorry!)
Using finger zooming lets me do exactly what I want, but at the moment the `auto zoom lock` only seems to come on when you get to 200% zoom on the final level (or close to it, with finger zoom).
So if I have reached the last zoom level of my saved map, and I want to finger zoom to anything up to 150%, it will snap back to 100%.
If I want say 140%, I have to either
(a) turn zoom lock on manually, or
(b) zoom to 200% first (so zoom lock comes on automatically), and then back to 140%
It would be more useful if the auto zoom lock came on as soon as you start to finger zoom above the last level (so with anything over 100%), rather than only when it reaches 200%
If I want to zoom in between any of the other map levels, I am happy to turn on zoom lock manually.
Sorry to be fussy. I really like the auto zoom lock feature, but feel it could be improved a little.
Thankyou - I`ve had a play around and now I understand how the snapping work. I tend to use +/- volume for zooming and haven`t used finger zoom very much - I shall have to start using it more.
However - this means I have another request (sorry!)
Using finger zooming lets me do exactly what I want, but at the moment the `auto zoom lock` only seems to come on when you get to 200% zoom on the final level (or close to it, with finger zoom).
So if I have reached the last zoom level of my saved map, and I want to finger zoom to anything up to 150%, it will snap back to 100%.
If I want say 140%, I have to either
(a) turn zoom lock on manually, or
(b) zoom to 200% first (so zoom lock comes on automatically), and then back to 140%
It would be more useful if the auto zoom lock came on as soon as you start to finger zoom above the last level (so with anything over 100%), rather than only when it reaches 200%
If I want to zoom in between any of the other map levels, I am happy to turn on zoom lock manually.
Sorry to be fussy. I really like the auto zoom lock feature, but feel it could be improved a little.
There is something buggy with zoom-in on doubletap and zoom-out on two-finger tap with the new new auto zoom lock feature. It`s a bit hard to describe: zoom-in always seems to work (testing a moderate rmap here and doubletap-zoom-in until 14/800%). twofinger-tap zoomout works once to 14/400% but then it stops working. I cannot get back to 14/200%. The map name text string goes to 14/800(?) and back to 14/400 immediately.
It works when using the - button.
Edit: confirmed with other RMAPs. Doubletap-Zoom-In always works, Doubletap-Zoom-Out only works exactly once when bitmap scaling.
Edit: On a related note, bitmap scaling seems quite slow here in general. I cant really see what would take Locus so long (almost a second) to scale a few tiles. What classes/methods are used here? There must be something faster somewhere. Investing a bit of work in this area would make the app feel *a lot* snappier IMHO.
There is something buggy with zoom-in on doubletap and zoom-out on two-finger tap with the new new auto zoom lock feature. It`s a bit hard to describe: zoom-in always seems to work (testing a moderate rmap here and doubletap-zoom-in until 14/800%). twofinger-tap zoomout works once to 14/400% but then it stops working. I cannot get back to 14/200%. The map name text string goes to 14/800(?) and back to 14/400 immediately.
It works when using the - button.
Edit: confirmed with other RMAPs. Doubletap-Zoom-In always works, Doubletap-Zoom-Out only works exactly once when bitmap scaling.
Edit: On a related note, bitmap scaling seems quite slow here in general. I cant really see what would take Locus so long (almost a second) to scale a few tiles. What classes/methods are used here? There must be something faster somewhere. Investing a bit of work in this area would make the app feel *a lot* snappier IMHO.
it was worst then I expect ...
As you already know, I would like to release today new version. So if someone will have some time, short test is more then welcome
https://dl.dropbox.com/u/8015949/2.5....
PS: I know that "loading" of new tiles is not nice. This is anyway another "idea" here on GS so ignore it for now ..
it was worst then I expect ...
As you already know, I would like to release today new version. So if someone will have some time, short test is more then welcome
https://dl.dropbox.com/u/8015949/2.5....
PS: I know that "loading" of new tiles is not nice. This is anyway another "idea" here on GS so ignore it for now ..
Hi menion,
zooming with the fingers looks good.
Hi menion,
zooming with the fingers looks good.
new version tested. mostly good i think, except for the slowness :-).
when you finger zoom into bitmap scale regions (like 15/252%) and then zoom out with the button, it does not snap to closest 100% level but instead goes to 15/126%. snapping to levels on button zoom is only active when you are in map zoom level regions. not sure if that is good or not.
new version tested. mostly good i think, except for the slowness :-).
when you finger zoom into bitmap scale regions (like 15/252%) and then zoom out with the button, it does not snap to closest 100% level but instead goes to 15/126%. snapping to levels on button zoom is only active when you are in map zoom level regions. not sure if that is good or not.
I created really complex algorithm :) If you zoom out from more then 200%, it firstly zoom to half (as usually) and when you`re below 200%, next zoom-out will snap to full 100%
imagine you start with for example 640%, zoom out to 320%, zoom out to 160%, then zoom out to non-scaled 100%. We`ll see if this will work ...
and slowness - main problem is that I use CPU for map rendering and not graphics card. OpenGL is missing more and more, but I need around a month just to learn basics and there is still so much things to do :)
I created really complex algorithm :) If you zoom out from more then 200%, it firstly zoom to half (as usually) and when you`re below 200%, next zoom-out will snap to full 100%
imagine you start with for example 640%, zoom out to 320%, zoom out to 160%, then zoom out to non-scaled 100%. We`ll see if this will work ...
and slowness - main problem is that I use CPU for map rendering and not graphics card. OpenGL is missing more and more, but I need around a month just to learn basics and there is still so much things to do :)
Erm... I believe there are methods that scale simple 2D bitmaps with hardware acceleration, even without àll the OpenGL fuss. Maybe its just a matter of setting the proper flags in your Paint context or whatever and enabling hw acceleration in your Manifest? Sorry if this is all bullshit, I am just fishing in the dark here. Obviously a full blown OpenGL display engine would be better, I am still amazed about what TwoNav does. But I still cant believe that Android would not also scale simple 2D speedily with hardware.
Some docs from google on this are here:
http://developer.android.com/guide/to...
Erm... I believe there are methods that scale simple 2D bitmaps with hardware acceleration, even without àll the OpenGL fuss. Maybe its just a matter of setting the proper flags in your Paint context or whatever and enabling hw acceleration in your Manifest? Sorry if this is all bullshit, I am just fishing in the dark here. Obviously a full blown OpenGL display engine would be better, I am still amazed about what TwoNav does. But I still cant believe that Android would not also scale simple 2D speedily with hardware.
Some docs from google on this are here:
http://developer.android.com/guide/to...
seems you want discuss it in more professional way :)
ok, in this case, I use matrix object for rescaling bitmap on the fly ...
when I simplify it a little, something like this
matrix.preScale(scaleX, scaleY)
matrix.postTranslate(drawX, drawY)
canvas.drawBitmap(bitmap, matrix, paint)
I`ll anyway check for some paint parameters, if there is not any space for improving ...
EDIT: ah, one more not. During pinch zoom is doing much more coordinate transformations, so if you have visible more points, there should be now significant performance reduction. Maybe this is your case
seems you want discuss it in more professional way :)
ok, in this case, I use matrix object for rescaling bitmap on the fly ...
when I simplify it a little, something like this
matrix.preScale(scaleX, scaleY)
matrix.postTranslate(drawX, drawY)
canvas.drawBitmap(bitmap, matrix, paint)
I`ll anyway check for some paint parameters, if there is not any space for improving ...
EDIT: ah, one more not. During pinch zoom is doing much more coordinate transformations, so if you have visible more points, there should be now significant performance reduction. Maybe this is your case
Nope... not a single point or track visible. Its just the map. I really dont have much clue about Android, sorry. I was just confused how scaling can be that slow. I mean, obviously the Galaxy Note has quite a high resolution. But stil... one second per scroll redraw is simply way too much. So i was hoping that there might simply be a missing flag in the manifest or something like
Window.setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
If it`s only a few flags and some minor changes in rendering to get a major speedup, it might well be worth investing a little time here. Even when everything will change to OpenGL at some point in the future.
Maybe you could add a debug printf of view.isHardwareAccelerated() to Locus? Then we could tell whats up with the map view and if it is really scaling with the cpu.
Nope... not a single point or track visible. Its just the map. I really dont have much clue about Android, sorry. I was just confused how scaling can be that slow. I mean, obviously the Galaxy Note has quite a high resolution. But stil... one second per scroll redraw is simply way too much. So i was hoping that there might simply be a missing flag in the manifest or something like
Window.setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
If it`s only a few flags and some minor changes in rendering to get a major speedup, it might well be worth investing a little time here. Even when everything will change to OpenGL at some point in the future.
Maybe you could add a debug printf of view.isHardwareAccelerated() to Locus? Then we could tell whats up with the map view and if it is really scaling with the cpu.
one second per redraw??? ah, OK, I`ll do some benchmarks and test it ...
anyway I`m setting and using Software layet type
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
there is nice article about it http://android-developers.blogspot.cz.... I was already playing with it around an year ago. Problem with it is that by enabling hardware acceleration, there are some features that will not work and that I need for some basic stuff ... anyway, leave it for now and I`ll check it more in next days ...
one second per redraw??? ah, OK, I`ll do some benchmarks and test it ...
anyway I`m setting and using Software layet type
view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
there is nice article about it http://android-developers.blogspot.cz.... I was already playing with it around an year ago. Problem with it is that by enabling hardware acceleration, there are some features that will not work and that I need for some basic stuff ... anyway, leave it for now and I`ll check it more in next days ...
I remember reading something about ICS supporting more features on HW accelerated layers. Maybe it could be enabled for ICS only. Oh well... good luck playing with it, I am eagerly awaiting the results :).
I remember reading something about ICS supporting more features on HW accelerated layers. Maybe it could be enabled for ICS only. Oh well... good luck playing with it, I am eagerly awaiting the results :).
maybe you`re right. Looks there are visible problems only with track floating on map, nothing more.
You`re motivating me to more focus on this task :) ... check this https://dl.dropbox.com/u/8015949/2.5.... ... enabled Hardware acceleration for a whole application
maybe you`re right. Looks there are visible problems only with track floating on map, nothing more.
You`re motivating me to more focus on this task :) ... check this https://dl.dropbox.com/u/8015949/2.5.... ... enabled Hardware acceleration for a whole application
woooooooooooooahhhhhhhhhhhh.... thats what i call smooth!
woooooooooooooahhhhhhhhhhhh.... thats what i call smooth!
i am majorly impressed. thats like tenthousand times faster than it was.
until i enabled a dozen tracks with a few thousand points each at least. the tracks still seem to slow down locus a lot, even when they are hundreds of kilometers away and not visible at all. i wonder why that is.
but never mind, this should be about zooming and hardware accel. and it is WAY COOL!
i am majorly impressed. thats like tenthousand times faster than it was.
until i enabled a dozen tracks with a few thousand points each at least. the tracks still seem to slow down locus a lot, even when they are hundreds of kilometers away and not visible at all. i wonder why that is.
but never mind, this should be about zooming and hardware accel. and it is WAY COOL!
Brilliant! Very happy with the improved zooming. A much better solution than my original suggestion. Cheers :)
Brilliant! Very happy with the improved zooming. A much better solution than my original suggestion. Cheers :)
you`re welcome skids :)
and joeloc, I`m really surprised. On my phone (Galaxy Nexus) I see no difference!! Interesting ... support for this brings mainly troubles, few important things do not work as I discovered etc. I`ll try to do something but cannot promise. Anyway if this is such huge difference on your phone (and probably not only your), it will have possitive impact also on battery, so it have to be improved. What phone and android version are you using?
PS: seems to be little bit off-topic now
you`re welcome skids :)
and joeloc, I`m really surprised. On my phone (Galaxy Nexus) I see no difference!! Interesting ... support for this brings mainly troubles, few important things do not work as I discovered etc. I`ll try to do something but cannot promise. Anyway if this is such huge difference on your phone (and probably not only your), it will have possitive impact also on battery, so it have to be improved. What phone and android version are you using?
PS: seems to be little bit off-topic now
I havent really noticed any problems with displaying things yet. But anyway, none of these problems can be bad enough to NOT use hardware accel in the future. Locus almost feels like a completely new app now, the speed increase is at least fifty(50!) times for me. I am quite surprised that there is no difference at all on the Galaxy Nexus. Maybe, depending on the Android version and your Manifest and the moon phase, Android uses different defaults for the scaling methods? It might have been using partial hardware accel all along on some phones, who knows.
I am using Android 4.0.4 (N7000XXLA4) on a Galaxy Note with a CM9 Kernel. The ROM is called "ParanoidAndroid" btw and quite funky. I can put each app into either tablet or phone mode and adjust the dpi separately.
I havent really noticed any problems with displaying things yet. But anyway, none of these problems can be bad enough to NOT use hardware accel in the future. Locus almost feels like a completely new app now, the speed increase is at least fifty(50!) times for me. I am quite surprised that there is no difference at all on the Galaxy Nexus. Maybe, depending on the Android version and your Manifest and the moon phase, Android uses different defaults for the scaling methods? It might have been using partial hardware accel all along on some phones, who knows.
I am using Android 4.0.4 (N7000XXLA4) on a Galaxy Note with a CM9 Kernel. The ROM is called "ParanoidAndroid" btw and quite funky. I can put each app into either tablet or phone mode and adjust the dpi separately.
Hmm I just think that is next nice example how applications works differently on various devices ... anyway, I`m measuring some rendering times and hardware acceleration speed up rendering on GN 3times. Frame rate with software rendering is high enough (around 50 frames per sec)
Except some problems, I discovered one big surprise for me ... I think you all will be nicely surprised in near future if all will be fixable ...
Hmm I just think that is next nice example how applications works differently on various devices ... anyway, I`m measuring some rendering times and hardware acceleration speed up rendering on GN 3times. Frame rate with software rendering is high enough (around 50 frames per sec)
Except some problems, I discovered one big surprise for me ... I think you all will be nicely surprised in near future if all will be fixable ...
Btw... I sometimes have disappearing tracks with the hw accel version. But I guess you know that already. Also, sometimes a football icon (no kidding) appears under the cursor. Quite funny :).
Edit... ok... forget about the football icon. That was probably a new version of a mapsforge map. And in fact it actually appears right on top of a soccer field...
Btw... I sometimes have disappearing tracks with the hw accel version. But I guess you know that already. Also, sometimes a football icon (no kidding) appears under the cursor. Quite funny :).
Edit... ok... forget about the football icon. That was probably a new version of a mapsforge map. And in fact it actually appears right on top of a soccer field...
you may be lucky that tracks only disappear (btw. very weird that it works quite different on your device). I have much more problems with tracks so it`s currently not possible to publish it officially.
Main problem is that this hardware acceleration is able to draw only paths (tracks) to 2048x2048 pixels. So if you zoom more, track will be hidden. Only idea I have is to draw tracks line by line, but this will be really ugly because on all points will not be smooth corners ... hard work ...
you may be lucky that tracks only disappear (btw. very weird that it works quite different on your device). I have much more problems with tracks so it`s currently not possible to publish it officially.
Main problem is that this hardware acceleration is able to draw only paths (tracks) to 2048x2048 pixels. So if you zoom more, track will be hidden. Only idea I have is to draw tracks line by line, but this will be really ugly because on all points will not be smooth corners ... hard work ...
ugly is bad :)
Hmm... i guess clipping the track manually is not really possible. Needs too much cpu juice, unless you arrange all your geo data in R-Trees or something.
Another idea might be to draw the tracks into a non-hardware-accelerated buffer bitmap and then blit this bitmap on top of the real one with hw accel.
Or do it like now when its less than 2048, I guess leaving it to the hardware will be the most efficient thing to do anyway? And when its larger because of too much zooming, do it line by line and ugly.
ugly is bad :)
Hmm... i guess clipping the track manually is not really possible. Needs too much cpu juice, unless you arrange all your geo data in R-Trees or something.
Another idea might be to draw the tracks into a non-hardware-accelerated buffer bitmap and then blit this bitmap on top of the real one with hw accel.
Or do it like now when its less than 2048, I guess leaving it to the hardware will be the most efficient thing to do anyway? And when its larger because of too much zooming, do it line by line and ugly.
Btw, I have kind of realized why some phones/ROMs were incredibly slow before this GPU change and some werent. Apparently, Android can force apps into some sort of GPU rendering mode, even if the app itself does not specify that. When you check a few home brewn custom ROMs, some have an option called "forced GPU rendering" enabled. Maybe this is a compile time option for the Kernel or just a flag somewhere... but it exists and apparently it speeds up "unwilling" apps a lot.
Btw, I have kind of realized why some phones/ROMs were incredibly slow before this GPU change and some werent. Apparently, Android can force apps into some sort of GPU rendering mode, even if the app itself does not specify that. When you check a few home brewn custom ROMs, some have an option called "forced GPU rendering" enabled. Maybe this is a compile time option for the Kernel or just a flag somewhere... but it exists and apparently it speeds up "unwilling" apps a lot.
good to know thanks. I have also some more important work to do, so expect that new version will be again with disabled hardware acceleration but I`ll do something with it soon. It looks very promising and mainly useful
good to know thanks. I have also some more important work to do, so expect that new version will be again with disabled hardware acceleration but I`ll do something with it soon. It looks very promising and mainly useful
Hm, Iwould like to ask two more things about zooming:
• why de/activating the zoom lock function does automatically changes the zoom factor? I would feel more comfortable, when the screen won`t jump to 200% zoom but stay on the actual 70% or whatever...
• what about one additional configuration to set the "snapping granularity" for pinch zooming? I could imagine, that some user like to have "exact" zooming (e.g. to 137%), other user would only like to see zoom factors like 100%, 150% etc.
Hm, Iwould like to ask two more things about zooming:
• why de/activating the zoom lock function does automatically changes the zoom factor? I would feel more comfortable, when the screen won`t jump to 200% zoom but stay on the actual 70% or whatever...
• what about one additional configuration to set the "snapping granularity" for pinch zooming? I could imagine, that some user like to have "exact" zooming (e.g. to 137%), other user would only like to see zoom factors like 100%, 150% etc.
1. many people don`t know what this feature do. In previous versions, zoom just stays as was. Like you write. So nothing happen and many people wrote us .. " what this button do"?. Zoom-lock is usually used for increasing resolution so I now change zoom automatically to 200% to show them "what this feature do". Anyway it`s possible to keep current zoom value if this value is different then 100%, right?
2. I don`t think it`s necessary. Two possibilities that are now (so keep exact zoomed value or snap to 100%) is enough
1. many people don`t know what this feature do. In previous versions, zoom just stays as was. Like you write. So nothing happen and many people wrote us .. " what this button do"?. Zoom-lock is usually used for increasing resolution so I now change zoom automatically to 200% to show them "what this feature do". Anyway it`s possible to keep current zoom value if this value is different then 100%, right?
2. I don`t think it`s necessary. Two possibilities that are now (so keep exact zoomed value or snap to 100%) is enough
Understood.
Maybe the icon for this button should have shown only the locker without the magnifying glass to understand the functionality...
Understood.
Maybe the icon for this button should have shown only the locker without the magnifying glass to understand the functionality...
hmm we already though about it, but was worried that only "lock" icon, with lead people to thing that it locks screen and map, and not just zoom. That ̈s why it`s combined with zoom icon ... but we`ll think about it. Truth is that it needs some small improvement to make it more clear
hmm we already though about it, but was worried that only "lock" icon, with lead people to thing that it locks screen and map, and not just zoom. That ̈s why it`s combined with zoom icon ... but we`ll think about it. Truth is that it needs some small improvement to make it more clear
Looked so clear for me at the first moment, but now I see how difficult is is, to avoid confusion for each type of user...
...maybe something like the rotation button (hopefully it is called like that in english) on the same function bar could be used, which allows to set different options (rotate map and show the view angle). So the lock button could allow to lock the zoom factor or the map center (or whatever other users will think to be useful).
Looked so clear for me at the first moment, but now I see how difficult is is, to avoid confusion for each type of user...
...maybe something like the rotation button (hopefully it is called like that in english) on the same function bar could be used, which allows to set different options (rotate map and show the view angle). So the lock button could allow to lock the zoom factor or the map center (or whatever other users will think to be useful).
X 6 FT
O 7
O 8
O 9
X 10
O 20
X 30
O 40
X 50
O 60
O 70
O 80
O 90
X 100
X 200
O 300
X 400
O 500
O 600
O 700
X 800
O 900
O 0.2 mi
X 0.3
O 0.4
O 0.5
X 0.6
O 0.7
O 0.8
O 0.9
X 1.0
and so on.
X 6 FT
O 7
O 8
O 9
X 10
O 20
X 30
O 40
X 50
O 60
O 70
O 80
O 90
X 100
X 200
O 300
X 400
O 500
O 600
O 700
X 800
O 900
O 0.2 mi
X 0.3
O 0.4
O 0.5
X 0.6
O 0.7
O 0.8
O 0.9
X 1.0
and so on.
Replies have been locked on this page!