949650 - [B2G][Browser][PDFViewer]Performance issues viewing large PDFs in Portrait and Landscape mode on device

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::PDF Viewer, defect, P2)

Description

[Montoya Clemmons (MClemmons)]

Attachment: LogcatPDFviewer evidence

Selecting a 31-page PDF (1.1 MB) within browser app demonstrates negative performance issues in portrait and landscape modes. The PDF viewer displays the file has loaded with the bar slider filled from left to right. However, only elements of the pages (header) display with the blue spin wheel showing on page user is on. When user taps the forward or back arrows to go to other pages, at between the 5th and 10th attempt for previous or next page, the user is taken out of the PDF entirely.

Repro Steps: 
1) Updated buri to BuildID: 20131210004003 
2) Tap Browser App 
3) Clear cache and stored data and browser history in browser settings 
4) Go to Google.com 
5) In search bar, type arod PDF suit 
6) Tap first search result (Suit against MLB, Selig (PDF) - ESPN.com - Go.com)


Actual: 
Page loads completely per the black bar changing white as time elapses (less than 5 seconds) but text does not display as is the case using FireFox Browser for PC. Scroll through approximately 5-10 pages normally or tapping the previous or next page arrows approximately 5-10 times normally sends user back to the Google search results page regardless if user is in landscape or portrait mode 

Expected: 
Page loads completely and text viewed and user able to scroll or navigate pages normally without being forced back to the results page. 

Environmental Variables: 
Device: buri 1.3 MOZ 
BuildID: 20131210004003 
Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f 
Gecko: e0c328d99742 
Version: 28.0a2 
RIL Version: 01.02.00.019.102 

Notes: 
Repro frequency: (15/15 - 100%) 
Link to failed test case: https://moztrap.mozilla.org/manage/case/4931/ 
See attached: URL video clip of demonstration for landscape and portrait modes
See attached: logcat of performance issue

Comment 1

[Montoya Clemmons (MClemmons)]

I was able to reproduce this issue on Buri 1.2 Mozilla using the below Environmental Variables:

Device: buri 1.2 moz
BuildID: 20131212004004 
Gaia: 6d02039072a2ae5cf9225a6f4c78ed49decfab5c 
Gecko: 8bae10bb0aed 
Version: 26.0 
RIL Version: 01.02.00.019.102

Comment 2

[Montoya Clemmons (MClemmons)]

I was able to reproduce this issue on Buri 1.1 Mozilla using the below Environmental Variables:

Device: buri 1.1 MOZ
BuildID: 20131210041202
Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f
Gecko: 05117f42088f
Version: 18.0
RIL Version: 01.02.00.019.102

Comment 3

[Hubert Figuiere [:hub]]

The document is directly at URL:

http://espn.go.com/pdf/2013/1004/arod-suit.pdf

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

So is this a problem with pdf.js or with the Gaia integration?

Comment 5

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #4)
> So is this a problem with pdf.js or with the Gaia integration?

Probably pdf.js itself. There's very little we do in Gaia integration with pdf.js overall.

Comment 6

[Nicholas Nethercote [inactive]]

We're tracking MemShrink stuff for pdf.js in bug 881974.

Comment 7

[Nicholas Nethercote [inactive]]

This is a scanned PDF document, so the patches in bug 959925 should help greatly -- each page is 34 MiB when decoded to raw pixel data, and those patches reduce the number of copies of that data from five to one. (Even one copy of 34 MiB of data is pushing it for B2G, and you'll get in trouble if you scroll quickly due to bug 962351, but you might have a chance if you scroll slowly.)

Those patches have landed in the pdf.js GitHub repository, and will be imported into mozilla-central in bug 960051. I'm guessing we'll need to update the version of pdf.js used for FxOS 1.3.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Nicholas Nethercote [:njn] from comment #7)
> This is a scanned PDF document, so the patches in bug 959925 should help
> greatly -- each page is 34 MiB when decoded to raw pixel data, and those
> patches reduce the number of copies of that data from five to one. (Even one
> copy of 34 MiB of data is pushing it for B2G, and you'll get in trouble if
> you scroll quickly due to bug 962351, but you might have a chance if you
> scroll slowly.)
> 
> Those patches have landed in the pdf.js GitHub repository, and will be
> imported into mozilla-central in bug 960051. I'm guessing we'll need to
> update the version of pdf.js used for FxOS 1.3.

I'll file a bug to update the pdf.js in Gaia to the latest available.

Comment 9

[Nicholas Nethercote [inactive]]

BTW, if you're wondering where the 34 MB comes from: US letter paper is 8.5 x 11 inches. If scanned at 300 dpi, that's 8,415,000 pixels. Convert each pixel to a 32-bit RGBA value, and you get 33,660,000. In the documents I've seen the pixel count per page varies slightly, but it's always close to 34 MB.

It sucks that for black and white documents that we have to blow up the data size by 4x, but canvas requires that input data be in 32-bit RGBA format. So we actually need about 42.5 MB for one page's data -- 8.5 MB for the original grayscale data, and then 34 MB for the RGBA data.

The only way I can see to reduce this would be to cut the image into slices and process one slice at a time, but that's tricky given the architecture -- the RGBA data is unpacked in the worker, and then passed to the main thread for the actual canvas drawing, and the main thread code is very much architected around getting the image's data in a single buffer.

Comment 10

[Nicholas Nethercote [inactive]]

> It sucks that for black and white documents that we have to blow up the data
> size by 4x, but canvas requires that input data be in 32-bit RGBA format. So
> we actually need about 42.5 MB for one page's data -- 8.5 MB for the
> original grayscale data, and then 34 MB for the RGBA data.

Actually, we can do much better than that. See bug 962933.

Comment 11

[Nicholas Nethercote [inactive]]

If someone (mclemmons?) can re-test this, it should be *much* better now.

Comment 12

[Montoya Clemmons (MClemmons)]

In response to  Nicholas Nethercote [:njn] 2014-02-10 14:52:08 PST

If someone (mclemmons?) can re-test this, it should be *much* better now.

I am experiencing similar behavior as reported in Comment 0 on the latest 1.3 Buri Build - environmental variables at the end of this comment. I was selecting the same linked PDF file (A-rod Suit) as reported in Comment 0.

In landscape mode, following the STR demonstrates the PDF not fully loaded and user redirected to the google search page without user input.

In portrait mode, following the STR demonstrates the PDF loading very deliberately and occasionally redirecting to the previous Google search page as is the case in landscape mode before load completes. However, when allowed to do so, swiping from page to page reproduced the reported behavior in Comment 0 of being redirected to the Google search page unexpectedly.

I have conducted 15 independent tests and was never allowed to view the entire document or to maneuver the pages normally.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Base image: V1.2-device.cfg

Comment 13

[Nicholas Nethercote [inactive]]

mclemmons: I thought that the relevant pdf.js changes had been imported to 1.3, but bug 966865 comment 17 indicates that hasn't happened yet. Sorry!

BTW, can you open other PDFs on your Buri? I'm unable to open even the simplest PDFs on my Buri. It always runs out of gralloc memory just as it's about to display the first page.

Comment 14

[Nicholas Nethercote [inactive]]

mclemmons, I believe the relevant changes are now in 1.3. If you could re-test, that'd be great.

Also, you marked 1.4 as being affected. Did you test on 1.4? (1.4 is still trunk, is that right?)

Comment 15

[Montoya Clemmons (MClemmons)]

(In reply to Nicholas Nethercote [:njn] from comment #14)
> mclemmons, I believe the relevant changes are now in 1.3. If you could
> re-test, that'd be great.
> 
> Also, you marked 1.4 as being affected. Did you test on 1.4? (1.4 is still
> trunk, is that right?)

I have retested on the latest 1.3 build and witnessed no changes. The page of the URL listed in both Comment 0 and Comment 3 did not load fully. Additionally, the user experience of being forced back to the page before the PDF file page from Comment 0 was reproduced in this test. 

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140310004001
Gaia: 78c30d7ed6f6e30337d6c05453b867f5e97e42bc
Gecko: 00f249d54bda
Version: 28.0

Yes, I did test on 1.4 Master when reported 2014-03-05

Comment 16

[Montoya Clemmons (MClemmons)]

Update to Comment 15 to include Environmental Variables with Base image:

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140310004001
Gaia: 78c30d7ed6f6e30337d6c05453b867f5e97e42bc
Gecko: 00f249d54bda
Version: 28.0
Base image: v1.2-device.cfg

Comment 17

[BMO Automation]

Firefox OS is not being worked on