Using the ZoomLayout inside a ViewPager

[tanis2000]

I'm trying to use ZoomLayout as the element of a ViewPager but I'm experiencing a weird issue when swiping to show the next/previous page. It looks like instead of making the new page slide in, it's like if I'm removing an overlay off a page that sits below the current page.

I suppose it's due the layout of the page coming in that is changing dimensions while sliding so that ZoomLayout is adapting the image in a weird way and the final effect is like I'm peeling a layer off a page under the current one. It's nice but it's not what I'm looking for.

Is there any way to temporarily disable this behavior so that it behaves just like an ImageView while sliding in?

Cheers!

[natario1]

Can you post a video of this issue?

And the XML where the ZoomLayout is

[markusressel]

Using multiple layers of gesture detection is generally a bad idea.
Did you try disabling swipe gestures in the viewpager?

[DoctorB]

2018_06_19_09_02_25_trim.zip
The swipe gestures in the viewpager was already disabled, anyway now it seems to work properly. We just added android:layerType="hardware" on the ZoomLayout

In the current attachment you can see how it was before to change the layerType

This is the layout loaded by the viewpager:

<?xml version="1.0" encoding="utf-8"?>
<com.otaliastudios.zoom.ZoomLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/toonZoomLayout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:scrollbars="none"
    android:layerType="hardware"
    app:hasClickableChildren="false"
    app:maxZoom="1"
    app:maxZoomType="zoom"
    app:minZoom="1"
    app:minZoomType="zoom"
    app:overPinchable="true"
    app:overScrollHorizontal="false"
    app:overScrollVertical="false">
    <FrameLayout
        android:id="@+id/master"
        android:layout_width="match_parent"
        android:layout_height="match_parent">
        <ImageView
            android:id="@+id/comicBackground"
            android:layout_width="match_parent"
            android:layout_height="match_parent" />
    </FrameLayout>
</com.otaliastudios.zoom.ZoomLayout>

[natario1]

Would have to go into the ViewPager internals to see what's wrong. I'll leave this open...

About your XML, note that

• For images you can use ZoomImageView
• The content inside ZoomLayout should generally be wrap_content

[tanis2000]

I managed to reproduce the issue in a controlled environment.
Here's a sample repository with the code that behaves erroneously: https://github.com/tanis2000/ZoomLayoutInsideViewPager

If you check out this line: https://github.com/tanis2000/ZoomLayoutInsideViewPager/blob/master/app/src/main/res/layout/page.xml#L11 you'll notice that it's set to none. Apparently the other project I was referring to has something that forces that layout to avoid hardware rendering even though the manifest is set to use hardware acceleration.
If you change this line to "hardware" everything works fine.

[natario1]

Thanks! What if you use hasClickableChildren=true instead of false?

I guess the software Canvas somehow is unable to translate, but if you use hasClickableChildren=true, we don't directly use canvas translations.

[tanis2000]

Weird. Setting hasClickableChildren to true actually makes it behave correctly even though everything is slow due to the software rendered, but that's as expected. Why is hasClickableChildren making a difference?

[natario1]

If we have clickable children we use high-level (expensive) APIs child.setTranslation and child.setScale to animate.

If the flag is off we move the Canvas around when drawing because we don't care about clicks.

For some reason the software Canvas is not reacting to translations.

[tanis2000]

Ok, I wasn't aware of that. So far forcing hardware rendering seems the most reasonable solution. Is there anything I should be aware of when shipping with that option? Any known compatibility issues with old devices or anything like that?

[markusressel]

@tanis2000 I fear you have to find this out yourself. I don't think there are a lot of devices still out there that don't support hardware rendering but some cheap devices may still exist.

Closing this as the issue seems to be resolved.
@tanis2000 feel free to reopen if anything new comes up.

[tanis2000]

@markusressel so far everything is working fine for our client base. Cheers!