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
daemon.

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
that!

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 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).

dunno. i'm leaving that for romaxa :)

Comment 4 tuukka.tolvanen 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 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 2010-05-26 00:33:48 UTC

Seems to be fixed in PR1.2 (full flash) - thanks. Verifying.