Re: matching VCL to touch screen coordinates

Thanks.
We may implement this approach, or let the IOS scrollview handle this under
the hood. We will know exactly after considering the options.
Still, this does not solve the issue of precise scaling.
We need to be able to scale the zoom, to any screen value, as that is
standard touch behaviour. if not we will have to always scale the picture,
either up or down.
if we scale up, we will get bulky graphics. if we scale down, we will need
to render a canvas larger than that we will show, which will result with
both scaled (rather than sharp) graphics, and lesser performance (as the
bigger the canvas, the bigger the rendering cost).
The only way to solve this, is to be able to give scaling instructions,
with a double/float granularity, rather than integer / long - or - multiply
the zoom factor by say, a 1000, allowing us finer precision over the zoom.
The only question is how to do it, and with the least risk to damage other
components, relying on the zoom mechanisms.

btw, this is why i prefer double/float over multiplying zoom by say, a
1000, as within the scale of a reasonable zoom (1% to 1000%), the
conversion from floating point to integer is non reductive and automatic -
meaning whoever is relying on the zoom to be as is, will be able to
continue working, via a simple cast, which possibly will be added
automatically by the compiler.

ptyl


On Mon, Aug 12, 2013 at 2:01 PM, Noel Grandin <noel@peralex.com> wrote:

> On 2013-08-11 19:47, Ptyl Dragon wrote:
>
> > additionally, we are trying to get the zoom to be continuous, so to
> > follow a pinch gesture as native touch devices do. currently, i believe
> > zooming is done in integers, representing percentages. we need to get it to
> > work with float or double values, so to allow the
>
> Zooming on mobile devices is tricky. To make it smooth, you will need to
> implement a mobile-specific strategy.
>
> Typically, the way that zooming on mobile devices works is this
> - when zooming, the UI enters a special ZOOMING state
> - when zooming in, the zoom code asks the underlying code to render a
> bitmap target about twice the size of the current screen.
> Then it uses the mobile device graphics framework, typically the on-board
> GPU , to rescale as need be.
> - it typically does the rendering to bitmap from outside the main thread
> - only when the zooming is over, does the zooming code tell the UI to
> resize properly to the new target size
>
> This is why when zooming in or out slowly everything looks fine.
> But when you zoom quickly, you sometimes see jagged lines for a while.
> This is because the background did not have enough time to render a new
> target bitmap, so the zooming code is stuck with rescaling the old bitmap.
>
> HTH, Noel.
>
> Disclaimer: http://www.peralex.com/**disclaimer.html<http://www.peralex.com/disclaimer.html>


-- 

[image: appicon.png]


*Ptyl Dragon*

Twitter <http://www.twitter.com/cloudoninc> |
LinkedIn<http://www.linkedin.com/company/cloudon>
 | Facebook <http://www.facebook.com/cloudoninc> |
Blog<http://site.cloudon.com/blog>