FVWM: OpaqueMove smears windows content with fglrx 10.x and above

[Harald van Pee]

Hi,

since I use amd/ati driver fglrx with version 10.x (currently I use 11.1)
I have the problem that the content of a window which was moved fast around in
OpaqueMove mode becomes smeared. Depending on how fast and how long one moves
one can not read any text in that window.
Firefox redraws the window content directly after releasing the mouse (xterm
does not), but the window title and frames are still damaged until I change
the size of the window.
Slow Moving of the window does not result in smearing of the content.
Switching off OpaqueMove helps for most programs, but for example nedit has
still some problems.

Has anybody an idea what option in fglrx or fvwm one can use to avoid that
smearing?
With the kde desktop the problem does not occur.

I use debian lenny on my notebook with ati radeon HD 2400 XT graphics card and
the debian fvwm package.
I have also installed a self compiled fvwm 2.5.31 which works but have the
same problem.
I can not see this problem with fglrx 8.x or 9.x but the more recent drivers
has better support for my notebook.

Since I use lenny I have no problem with fvwm even not in combination with
beamers and openoffice or acroread, it just works.

Thanks,

Harald

[Thomas Adam]

Post by Harald van Pee
Hi,
since I use amd/ati driver fglrx with version 10.x (currently I use 11.1)
I have the problem that the content of a window which was moved fast around in
OpaqueMove mode becomes smeared. Depending on how fast and how long one moves
one can not read any text in that window.
Firefox redraws the window content directly after releasing the mouse (xterm
does not), but the window title and frames are still damaged until I change
the size of the window.
Slow Moving of the window does not result in smearing of the content.
Switching off OpaqueMove helps for most programs, but for example nedit has
still some problems.

Nothing FVWM can do about this. Sounds like a display driver issue to me.

-- Thomas Adam

[Harald van Pee]

Hi,

Post by Thomas Adam

Post by Harald van Pee
Hi,
since I use amd/ati driver fglrx with version 10.x (currently I use 11.1)
I have the problem that the content of a window which was moved fast
around in OpaqueMove mode becomes smeared. Depending on how fast and how
long one moves one can not read any text in that window.
Firefox redraws the window content directly after releasing the mouse
(xterm does not), but the window title and frames are still damaged until
I change the size of the window.
Slow Moving of the window does not result in smearing of the content.
Switching off OpaqueMove helps for most programs, but for example nedit
has still some problems.

Nothing FVWM can do about this. Sounds like a display driver issue to me.

this is also what I thought at the begining, but just as I want write a bug
report, I found out, that the problem does not exist with kde. Even the most
problematic nedit can be moved opaque as fast as my hand can do it with not
any smearing or corruption of the window.

Therefore I assume, that the window manager can, at least in principle, change
its behaviour in such a way that the problem goes away.

On the other hand with gnome I have the same problem as with fvwm.

Harald

Post by Thomas Adam
-- Thomas Adam

[Thomas Adam]

Post by Harald van Pee
Therefore I assume, that the window manager can, at least in principle, change
its behaviour in such a way that the problem goes away.

Depends. All opaquemovesize does consider the threshold under which moving
the window will make FVWM ignore any batched ConfigureNotigy requests sent.
This is in an attempt to reduce flickering of the window, and also for us to
update the window each time (c.f. "BugOpts FlickeringMoveWorkaround On").

The fact that you then get artifacts on the screen is a bug elsewhere,
either within the client not redrawing itself correctly, or your display
driver being useless.

Post by Harald van Pee
On the other hand with gnome I have the same problem as with fvwm.

Sure -- comparing WMs/DEs isn't likely useful here. I'm still going to
maintain it's not FVWM's problem.

-- Thomas Adam