The Android BUG (V)- WebView plug surfaceView caused disorder

The screen Android BUG (V)- WebView plug the use surfaceView caused Mansian

Before in debug flash 11 effect of ICS use (this version surfaceView, up and down the market, basically with nativeWindow)found a bug, bug phenomenon is shown in Figure 1 (visit http:/the/www.qiaqiafood.com, the body of the page is a flash):

 

 

 

Figure 1:Error pictures

 

 

 

Figure 2:Normal Image

Webpage loaded, no problem, but when the page drag up and down on the black area as shown in Figure 1, and the image display of cascading relationship is not normal.

The tracking process does not elaborate, and also spent a long time. On this issue:

Dump framebuffer data:

 

$Adb shell cat/dev/graphics/fb0>framebuffer.bin view the results, the framebuffer does flower, and consistent performance on the screen, which is not unexpected

 

2. Connected hierarchyviewer, analysis of the framebuffer, only to find that this is a good

3 the screencap-p/sdcard/screenshot.png found is also good

 

 

 

Phenomenon and reproducible method, next analyze the reasons.

The face of it, this problem with the drawing, is surfaceFlinger related. View state surfaceFlinger:

# Dumpsys SurfaceFlinger

Focus under BrowserActivity:

+ Layer 0x95cc0 (com.android.browser/com.android.browser.BrowserActivity)

     z = 21025, pos = (0,0), size = (1024, 600), isOpaque = 0, needsDithering = 0, invalidate = 0, alpha = 0xff, flags = 0x00000000, tr = [1.00, 0.00][0.00, 1.00]

     client = 0x918a8, identity = 40

     format = 1, activeBuffer = [1024x 600:1024, 1], transform-hint = 0x00, queued-frames = 0

           mBufferCount = 2, mSynchronousMode = 1, default-size = [1024x600], mPixelFormat = 1, mTexName = 3

           current:{crop = [0,0, -1, -1], transform = 0x00, current = 1}

           next:{crop = [0,0, -1, -1], transform = 0x00, FIFO (0)= {}}

            [00]state = FREE, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16875976105982, 0x919b0 [1024x600:1024, 1]

           >[01]state = QUEUED, crop = [0,0, -1, -1], transform = 0x00, timestamp = 16877388086666, 0x8b6a0 [1024x600:1024, 1]

 Region transparentRegion (this = 0x95e60, count = 1)

   [0, 211, 1014, 715]

 Region transparentRegionScreen (this = 0x95cf4, count = 1)

   [0, 211, 1014, 715]

  RegionvisibleRegionScreen (this = 0x95cd0, count = 2)

   [0, 0, 1024, 211]

   1014, 211, 1024, 552]

 Careful analysis of the output can be a problem:the area of​​the browser is a transparent area:

 

0,211, 1014, 715]

This area the whole activity (corresponding Surface), is divided into two visible region:

   [0, 0, 1024, 211]

   1014, 211, 1024, 552]

Scroll the browser page, and then view state of BrowserActivity, twice as change with position coordinates of the transparent area is not even with the scroll!

Create and render the process down surfaceView found:

The Android the surfaceView (General Game the video and browserplugin use one kind of view)in its layout area will be set to transparent (that is, burrowing), but its setting is done only at the time of the attachWindow. Such problems caused:transparent area are not updated when a page scroll when this transparent region of the boundary after the final synthesis hwComposer boundary, and scroll the contents of the surface on, causing hwcomposer together wrong.

Know the problem, the solution can also know.

Routine practice:the every time layout traversal viewHierarchy of transparent reset have done too much, but the impact was more complex (yet to find a feasible method of modifying)

workaround practice:composer to hwComposer the area, can not be considered transparent area (the current test, have not seen will cause the system to have a bad impact), let it take all of the surface area calculated (theoretically efficiency may influential, but no observations impact)

Modify the method to comment out [e-mail] in visibleRegionScreen the assignment:

   hwcl->visibleRegionScreen.rects =

           reinterpret_cast<hwc_rect_t const *>(

                   visibleRegionScreen.getArray (

                           &Hwcl->visibleRegionScreen.numRects));

 As for hierarchyviewer and the screencap get screenshot Why is a good strategy?Here you can take a look at the screenshot realization (medium in surfaceFlinger), this screenshot and framebuffer synthesis is not the same thing, screenshot is not used hwcomposer just openGL each layer directly draw to FBO here burrow area actual calculation of the area and the workaround is not too bad.

 

In addition there are two problems:

1. The scroll window and the initial load flash (slower than pages), flash cover the navigation bar problem, as shown in Fig.

   

    Figure 3:surfaceView overlap BrowserActivity

Web Scroll when flash content scroll and browser content synchronization problem, not synchronized region would have a black box.

 Covered surfaceView default is placed on the surface in front of the browser, no solution, the solution can only be surfaceView on borwser behind (as I said before, because of the surface achieve burrow (transparent)function, in fact, on the back can be resolved)

 

Not synchronized, see the introduction of this year google IO webview on this surfaceView should......