9994 - [PP]No double-buffering on repaints.

Status: VERIFIED DUPLICATE of bug 12860

(Core Graveyard :: GFX, defect, P3)

Description

[moshev]

With M8,
any repaint, be it scrolling of a long page, resizing of rendered page, or
any other re-rendering, does not do double-buffering, as a result a lot
of flickering is seen, and black/grey backgrounds are painted before
the actual rendered page is drawn.

Comment 1

[leger]

Updating eng/qa contact

Comment 2

[troy]

Why is this assigned to me, double-buffering is the view code and has nothing to
do with layout? Come on Gramps, but a little effort into the bug processing...

Comment 3

[Patrick C. Beard]

I don't see this, unless you mean that lots of indpendent redraws are done. Each

view is redrawn independently by design. This does prevent flicker, but doesn't

necessarily give the best results.

Comment 4

[Patrick C. Beard]

Is this a linux-only problem?

Comment 5

[moshev]

This should not be composer related, I submitted
it as a browser bug (the rendering problem is while browsing)
I don't know about other platforms but on linux
it flickers like hell on evry significantly busy page
(try slashdot or anything else of that order, try resizing the browser
window while you scroll etc.)

Comment 6

[leger]

petersen, please give us status on all platforms.Thanks!

Comment 7

[Chris Petersen]

Based on Jan's comments, I checked this problem on Win 98 and Mac 8.6 with
apprunner (1999072710).The flicker issue when scrolling does happen on Mac but
it's not as severe as Linux version. Under Win 98, the flicker issue is not
occuring.

Comment 8

[Chris Petersen]

Based on Jan's comments, I checked this problem on Win 98 and Mac 8.6 with

apprunner (1999072710).The flicker issue when scrolling does happen on Mac but

it's not as severe as the Linux version. Under Win 98, the flicker issue is not

occuring.

Comment 9

[moshev]

I looked at m9, and the bug persists.
Also on linux, there are flickers in scrollbars,
when menus are closed, parts of html are painted on the
toolbar and other nasty painting problems.

P.S. shouldn't this be scheduled to some milestone?

Comment 10

[Adam D. Moss]

A simple way to avoid the grey flash is to use:

gdk_window_set_back_pixmap (widget->window, NULL, 0);

after the widget has been realized.  This will instruct
X via GDK that the application itself will be handling
the complete draw to the newly-exposed area Real Soon Now so it
is unhelpful or even undesirable for X to explicitly clear it
in the meantime.

This isn't actually the desired result of having the right
content ready-calculated to spring up upon scrolling, but it
leave the contents of the invalidated area intact until the
new content is ready.  This is at least considerably more
desirable that the area-clearing behaviour perceptually as the
previous contents are likely to very much resemble the data
which will reside there shortly.

I spent a few hours last weekend ploughing through
the GTK code and adding the above function call to the
appropriate Realize handlers, but I have experienced
no joy (at least, not in this!).  Yet.

Comment 11

[ramiro]

I tried what you are suggesting a long time ago and it didnt seem to help.  The
flashing is due entirely to the guffaw effect.  You can see the same thing ona
GnomeCanvas if you have lots of objects, or if you zoomin alot.  Or with the
gimp, and a huge zoom.

In any case, we are thinking of doing entirely away with the usage of GtkLayout
since we dont have any native widgets in html content anymore.  The only thing
we need widget for is scrolling, and we will probably do that by a combination
of XCopyArea() and nsWindow::Invalidate() in nsWindow::Scroll().

Comment 12

[ramiro]

Marking dup of 12860.


*** This bug has been marked as a duplicate of 12860 ***

Comment 13

[moshev]

This bug was NOT originally files as a flicker
problem, although this is how it manifests itself,
my original intention was that i really think
that a double buffering should be implemented
everywhere in an application
of a scale such as mozilla.
The reason for this is that it is a fundamental way
of solving any kind of flicker, not only on scrolling but
on any other action. Lot's of linux applications really
lack this feature but i think mozilla should implement it.
(Double buffering is when you paint everything to an off-screen buffer,
and only when it's completely ready you paint this buffer on the
display)

Comment 14

[Chris Petersen]

Marking as verified duplicate of 12860.