OpenGL: Pinch zoom to magnify text fails

[sonora]

It may not be easy to fix, but let me trigger the investgation anyway: Using legacy rendering, if in bad light conditions like direct sunlight, and trying to read text on the map, you can use "pinch zoom and hold", i.e. pinch-zooming the map and leaving your fingers in position, to temporarily magnify a map area (including all text) without it getting re-rendered, this e.g. facititates reading small or tilted map text.

Using OpenGL rendering, this trick fails, because map text immediately disappears during the maneuver, thus is never magnified.

Any chance to fix OpenGL to support that trick again?

[vshcherb]

This wouldn't work with Intermediate zoom feature which we plan to fix. So text should be increased only with a setting of Text size.

[vshcherb]

15009

[sonora]

Let me perhaps reopen this to see if we can find a solution.

This issue is about (with the OpenGL engine) being able to use pinch zoom as an on-the-fly screen magnifier, like the V1 engine allows. (For text, contour lines, etc. in difficult lighting.)

The basic idea so far was if we could not simply during a pinch zoom action pause displaying the re-rendered screen content (produced in the background by the GPU) until the user takes the fingers off the screen, and before that simply display the scaled former bitmap.

We had interim linked this to #15009, but unfortunately the fix for that one did not solve this issue here.

[vshcherb]

I still don't think we should change anything, I don't think it's important feature but let's keep it open

[Gregor0000]

I think this feature is quite important and it is one of the major reasons, I don't use OpenGL rendering yet. It is so convenient to be able to increase the text size with pinch&zoom in situations where the readability of the screen is bad (bad light - too dark, too bright, when wearing sunglasses). For me, those situations happen all the time during my hikes. Increasing the overall text size is not a good solution: It clutters the map view and makes a good overview more difficult. I would very much appreciate if such a functionality could be implemented.

[sonora]

@Gregor0000 Exactly.

And it"s not just for text. It temporarily magnifies everything, e.g. also contour lines, which normally you may only have as a background feature with intentionally less visibility.

[sonora]

I wonder if the feature requested in this issue could not be achieved by wrapping the content of this method https://github.com/osmandapp/OsmAnd-core/blob/a37dfcced5fb0ce9f0783ee3707ea7aa6cf25545/wrappers/android/src/net/osmand/core/android/MapRendererView.java#L1734 in a condition like

public void onDrawFrame(GL10 gl) {
    if (!(OsmandMapTileView).isPinchZoomingOrRotating()) {

        (...)

    }
}

which would halt any re-rendering until the fingers are taken off the screen, just like the legacy renderer handles things...

[vshcherb]

Not sure whether it's a good idea to stop rerendering

[sonora]

With low confidence as yet, but I've done some research on this on and off: My tentative takeaway is that while you simply halt rendering, the display (or if desired only selected textures of it) can behave like a bitmap which you can scale exactly like in our legacy renderer (perhaps needing a trivial 2D scaling method), until you take the fingers of and let re-rendering resume.

[vshcherb]

It will break zoom out functionality as there it's needed to have rendering, I'm not sure it's a feature, it was a bug in legacy rendering cause it wasn't possible not to scale. Though for some users it turns to be a feature however we have text size

[sonora]

Yes, could certainly limit to apply only for zoom-in cases.

In my experience it's not really only about text, it's all sorts of stuff sometimes hard to see in e.g. bright sunlight.

I personally sometimes use for contour lines, where (and rightly so) we use small and thin font for the elevation labeling which you do not read very often. But in some situations you need to - a perfect use case for such a quick "temporary magnification". Or to quickly inspect a highway shield label you would also not like to permanently show overly large.

Workaround (but much clumsier) could be an explicit temporary screen-magnifier via special quick action button. But using pinch for this is just REALLY intuitive and convenient. :wink:

[sonora]

An alternative strategy could be this:

1. Capture the scale factor from the gesture detector during the pinch-zoom gesture (Matrix.scaleM(textMatrix, 0, scaleFactorFromPinch, scaleFactorFromPinch, 1.0f);)
2. When rendering text, apply the captured scale factor to the text’s transformation matrix before drawing it (renderTextWithMatrix(textMatrix);).
3. After the pinch-zoom gesture ends, update the text size based on the final scale factor and re-render the text at its new size.

[vshcherb]

Too much for me.... @sonora can you implement flag that will be enabled in your build and code could be shared. So you will continue to have own version with it.

Good place to have such code in Version class where we have flags for different builds (paid non paid ,...)

[sonora]

Will be happy to experiment with this, need to find some major time, I guess. :wink: The simple goal is to suggest the least intrusive solution which could be turned on/off via a single flag.

Major challenge for me currently is how in a class like e.g. MapRendererView.java belonging to osmand-core I can import something or create awareness of a gesture state which is e.g. handled here (OsmandMapTileView).isPinchZoomingOrRotating() in OsmAnd. Any hint for me?

[vshcherb]

Well you already maintain specific changes, the goal that you don't maintain specific code and maintain only 1 line of specific code in Version. All the rest could should be merged to master, later it could be specific Flavor build. We do very similar already to different market versions but we don't maintain separate code

[sonora]

Sure we can do that if you like! But at this point I was asking about our coding hygiene: I notice that classes we have in OsmAnd-core do never import any classes from OsmAnd, or am I wrong? So what's the procedure of choice to share methods or context between these?

[vshcherb]

Of course core is completely independent library and couldn't use any classes from OsmAnd, so in order to pass code https://en.wikipedia.org/wiki/Inversion_of_control should be used