465042 - Image zoom much slower on fennec (canvas) version.

Status: VERIFIED INVALID

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Description

[Oleg Romashin (:romaxa)]

Open URL and try to click on some pictures on N810... with the same xulrunner and testgtkembed it works smooth and fast, but with fennec "mb-cleanup" at least branch it is not smooth.

Comment 1

[Stuart Parmenter]

this is very fast for me with mb-cleanup, although i'm using a newer X server.

either way, it is too early to be filing mb-cleanup bugs.

Comment 2

[Oleg Romashin (:romaxa)]

Problem also very easily reproducible on normal fennec.
And here is the very big difference in scaling speed between TestGtkEmbed and fennec.
Also there are big difference if we are using 16bit Xrender scaling and 24 bit (which is seems not optimized, tested with patch from bug 386440 and Xserver patches from bug 459078).

When 24 bpp force option enabled TestGtkEmbed also works slower.
I will attach profile data for all of them.

Comment 3

[Oleg Romashin (:romaxa)]

Attachment: Fennec with force24bpp option enabled

Comment 4

[Oleg Romashin (:romaxa)]

Attachment: Fennec with disabled force24bpp option

Comment 5

[Oleg Romashin (:romaxa)]

Attachment: TestGtkEmbed with 16 bit offscreen images (no force24bpp)

Comment 6

[Oleg Romashin (:romaxa)]

Attachment: TestGtkEmbed with force24bpp option enabled

Comment 7

[Siarhei Siamashka]

Well, the comparison is not completely fair because Xomap is really missing some fastpath functions for scaling with 24bpp destination format, these can be added by Jeff's patches from bug #459078. But 16bpp graphics will be still (a bit) faster just because memory bandwidth requirements are lower and the performance is limited by memory speed. It can be clearly seen if looking at 'fbmemcpy_arm' cpu usage in oprofile report as an extreme example, but other pixel manipulation functions also benefit from having less data to be read/written.

Anyway, in this case looks like reading from flash (jffs2 decompression in kernel?) and jpeg decoding takes most of the time.

I remember that earlier Mozilla had some kind of timeot (15 seconds) and disposed of the image data from memory if there was no activity from the user. So all this this stuff had to be loaded/decoded again if the user tried to do some panning/scrolling, causing some noticeable delay. Maybe something similar can affect zooming in Fennec as well?

Comment 8

[Aakash Desai [:aakashd]]

Hey Stuart, what's the deal with this bug?

Comment 9

[Aakash Desai [:aakashd]]

Per the the comments below:

blassey: looking at the history, it was closed out and reopened
blassey: I'd suggest closing it again

Moving this to invalid.

Comment 10

[Biju]

sorry for bug spam.
Many of the bugs which are marked invalid, I see comments telling it occurred in one version or other. But later it was fixed due to 1) by backingout the patch which made regression or 2) by fixing some other bug.
So if we can identify the bug/patch/reason then we should state that and mark those as FIXED. If not mark as WORKSFORME in that case.