Bug 8010 - (int-143609) browser repaints after switching from contacts
: browser repaints after switching from contacts
Product: Browser
User interface
: 5.0/(2.2009.51-1)
: All Maemo
: Unspecified normal with 3 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: Oleg Romashin
: browser-bugs
: http://news.bbc.co.uk/
  Show dependency tree
Reported: 2010-01-14 23:46 UTC by timeless
Modified: 2010-05-26 00:33 UTC (History)
6 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description timeless (reporter) 2010-01-14 23:46:42 UTC

0. have a working wifi network enabled, active
1. open browser
2. enter http://news.bbc.co.uk and press enter
3. wait for the page to load
4. use ctrl-backspace to switch to the task switcher (dashboard?)
5. tap the top left corner to open the app launcher
6. tap the top right item (address book/contacts)
7. wait half a minute
8. tap the top left corner to switch to the task switcher (dashboard?)
9. the browser might flash at this point
10. tap the browser

according to the general views in bug 6669, the browser should never repaint.

the browser blanks to white and then repaints

for this *precise* set of steps (varying reduces the reproducibility)



User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en;
rv: Gecko/2010010300 Camino/2.1a1pre (like Firefox/3.0.18pre)
Comment 1 timeless (reporter) 2010-01-14 23:55:57 UTC
The Browser is actually two processes:
1. Browser User Interface ("tablet-browser-ui", /usr/bin/browser)
2. Browser Daemon / Gecko ("microb", /usr/sbin/browserd)

Obviously, gecko at some point has to paint something somewhere. But since they
are distinct processes on a real operating system with protected memory, they
somehow need to copy their picture of the world from one process to the other.

In fact, while both are busy, they both have to keep allocated memory (two
copies) of what you see or are likely to want to see. This memory is big and
expensive, assume it's 1024x800x32bit-color, that's roughly 3mb on just one
side. Doubled, you're talking about 6mb. That's a lot of memory. If the browser
is using those 6mb, then another app can't. In fact, the numbers I'm using are
probably way off, I think the buffer dimensions are probably bigger although
the colordepth might be lower. These numbers are just to explain why the
browser needs to do what it does:

The browser ui when inactive lets go of the memory it isn't using. This means
that when it gets reactivated, it needs to get the tiles again from the browser

Now, you will probably complain that there are two other views, the dashboard
and the one you saw flicker away. I believe that the one from the dashboard is
a transform of the one you saw flicker away, so i'm not sure it actually costs
memory (possibly just cpu cycles). 

I'm not entirely sure who is paying for the one you saw flicker away, it's
possible it's gtk and it's possible the browser can do a better job, but I'm
pretty sure this is what's happening.

Note that not letting go of memory we aren't using is incredibly rude and
totally not an option. You really do want to be able to use other applications
while leaving the browser open, after all, you made me file a bug about just

I'm going to leave this bug open, but I am most certainly not promising we will
do anything about it.
Comment 2 Neil MacLeod maemo.org 2010-01-15 12:16:40 UTC
Hi timeless, thanks for that...  :)

Obviously this isn't a major problem in the grand scheme of things, but because
the other apps don't suffer from this issue you can understand why it has been
raised as an issue for the browser - it's a cosmetic nasty, really.

Do you think there is any way that the repainting can be avoided or suppressed,
particularly as in my experience the repainted view appears to be exactly the
same as the initial view that appears immediately after the window/ui is
reactivated (hence why the repaint seems - to the layman at least - to be
completely unecessary).
Comment 3 timeless (reporter) 2010-01-15 13:19:10 UTC
dunno. i'm leaving that for romaxa :)
Comment 4 tuukka.tolvanen nokia 2010-01-16 14:49:48 UTC
Something similar was fixed for internal build 10.2010.02-6, afaiui suspending
paint out until we have a useful paint in. I haven't verified it against these
steps, someone might want to check that :)
Comment 5 Andre Klapper maemo.org 2010-03-15 20:51:44 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 6 Neil MacLeod maemo.org 2010-05-26 00:33:48 UTC
Seems to be fixed in PR1.2 (full flash) - thanks. Verifying.