After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95273 - moving windows as wireframes would improve performance on remote displays
moving windows as wireframes would improve performance on remote displays
Product: metacity
Classification: Other
Component: general
Other All
: Normal major
Assigned To: Metacity maintainers list
Metacity maintainers list
: 96182 119554 119607 121177 134656 (view as bug list)
Depends on:
Reported: 2002-10-09 12:13 UTC by Brian Cameron
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

proposed patch (23.80 KB, patch)
2002-10-31 17:26 UTC, Erwann Chenede
none Details | Review
additional info about the need for wireframe resizing (702 bytes, text/plain)
2002-11-15 13:44 UTC, peter.kievits
updated patch (23.78 KB, patch)
2002-11-25 14:43 UTC, Erwann Chenede
none Details | Review
Proposed patch for "reduced resources" mode (53.30 KB, patch)
2003-07-23 21:42 UTC, Havoc Pennington
none Details | Review
Backport to GNOME 2.2 (51.69 KB, patch)
2003-07-29 16:11 UTC, Havoc Pennington
none Details | Review

Description Brian Cameron 2002-10-09 12:13:06 UTC
When running Metacity via remote display (as is common on multi-user
systems such as a SunRay server), moving a window causes a lot of X
traffic, and is therefore very CPU intensive.

It would be nice to offer a setting which would just move a wireframe
of the window while the user has the mouse button depressed, only 
actually moving the window after the user has chosen the new location.
Comment 1 Havoc Pennington 2002-10-09 14:56:36 UTC
If we could somehow automatically detect remote/slow displays and
switch to wireframe, I'd be a lot more open to doing that.

*** This bug has been marked as a duplicate of 92618 ***
Comment 2 Brian Cameron 2002-10-21 08:52:02 UTC
Bob Doolittle, who leads Sun's SunRay effort had the following
comments about this bug.  Obviously SunRay architecture makes
heavy use of remote displays.  In my discussions with him he
has stated that no reliable technology currently exists for 
"automatically" detecting slow displays.

--Bob's comments follow--

I'm having difficulty seeing how 95273 is a duplicate of this
bug.  This bug says that it is the app's fault for the bad behavior
during resize.  95273 is about moves, not resizes, and most apps
won't need to do anything in this case.  95273 is saying that if
the display is remote the large volume of X traffic during an opaque
window move is undesirable.  In fact, many users don't want opaque
moves because they want to see what is under the window while it is
moving.  I've worked with X for 16 years and I've never come across
a window manager that didn't allow users to choose an option to
display wireframe during window moves.  I don't see how we can say
this is too hard to do when every other window manager does it, nor
do I see how we can say we won't offer it for the same reason.  Many
users prefer this behavior even with a local framebuffer.

In 95273 the suggestion is that it would be nicer to detect low
bandwidth.  How would you propose this would be done, in the
general case?
Comment 3 Havoc Pennington 2002-10-21 22:49:08 UTC
(aside: did you mean to reopen the bug this was a dup of, instead of 
this bug?)

There's a limited set of features that exist purely as a compromise
for "classic X" users (sloppy focus, autoraise, etc.) but this set has
to be limited. When you guys switched to metacity I went through the
dtwm man page for you and drew the line between things in the set of
"classic X compromise" features and things out, so you'd go into this
with eyes open; we can certainly rethink the line somewhat, but you
shouldn't expect a dramatic change in its general location. The
argument "some users prefer or have used on some other system option
XYZ" unfortunately justifies about 400 preferences, metacity has only
about 15 preferences, and needs to stay in that range. I think I've
been pretty fair about making this clear up front. My belief is that
if people want twm behavior, or fvwm2 behavior, they should run those
window managers.

Anyway, point being, I'm not very receptive to "other X WMs or
operating systems have had this and people got used to it" as an
argument. Metacity is an exercise in providing a more 
modern UI. And in any case I don't have time to add or maintain 
the 400 preferences, I only have time to babysit single 

In short, don't use this argument. ;-) I just get really wordy in 
explaining why I don't like it. This is the base philosophy of what 
metacity is, and if we change that there's really no point in 
metacity vs. other WMs out there that I don't have to maintain myself.

That said, there's a performance issue to address on SunRay.

I don't think we should cave and say wireframe is the only 
solution right away, but I won't rule it out.

One thing we can try is that the opaque move/resize is currently
rate-limited for number of updates; the allowed rate can be tweaked.

I would like to have better data on how slow a computer, or network
link, has to be for this to be a problem. And is it a problem 
only on push-pixels style network links a la SunRay/VNC, or does it
work fine if the remote display is actually an X display.
If the problem is pushing pixels, I would expect the outline-mode XOR
hack to push the same pixels that opaque move/resize does; why 
doesn't it? Or is the performance bottleneck in actually 
drawing lines and such to the framebuffer? If so for SunRay that 
should be on the server, not the client, if I understand 
what a SunRay is.
I would also like some idea of whether "problem" means 
"somewhat slow, but one can get over it" or "really unusable."

Frankly if SunRay can't handle this and at least be usable, I'm
surprised GNOME as a whole is even remotely usable. And it sure 
seems like move/resize would be lost in the noise for the 
load average on the server; what percentage of the time
that a person is logged in do they spend move/resizing?

Preferences are bad solutions to performance problems. They should not
be the first place we turn. Understand the problem, 
and try to really fix it, for everyone, out of the box...

One obvious solution is to offer _only_ wireframe mode, 
though I think that has a significant negative usability impact.

I'm also wary of the point in #92618, that this preferences workaround
means many people never fix their apps (or their windowing system), 
resulting in poor usability.

Comment 4 Havoc Pennington 2002-10-21 22:59:23 UTC
BTW my favorite object lesson in this area is nautilus.
nautilus 1.0 had a _ton_ of config options for various performance
tradeoffs, and the nautilus developers spent time 
writing the "fast" and "slow" codepaths, and making it possible 
to dynamically switch between them. This made nautilus much 
larger, and much buggier, and added months of development work.

Then Alex came along and just optimized the "slow and attractive"
codepath to be as fast as the "fast" codepath over a couple of weeks.
Doh. He proceeded to delete enormous hunks of useless code and remove 
all the config options.

move/resize is somewhat harder since some of the increased load 
will be coming from "whatever app is underneath what's being 
move/resized" - but we should at least check whether 80% of the 
problem is just nautilus redrawing the desktop, or something
like that.
Comment 5 Christophe Fergeau 2002-10-25 07:58:15 UTC
*** Bug 96182 has been marked as a duplicate of this bug. ***
Comment 6 Stephane Chauveau 2002-10-25 11:00:06 UTC
Havoc, you should stop thinking 'Peoples only using 
Gnome applications with 2Ghz Redhat pc on their desk". 
You can't expect to solve this problem by optimizing 
Nautilus or Gnome in general. There are plenty of 
non Gnome progams out there and performances over 
remote display will always be slow (at least for
peoples without a quick-ass connection).

Unless you find a way do improve the X protocol (and 
all other remote display protocol) and to make it 
available worldwide within a month, the only viable 
alternative is to reduce the number of redraw requests. 

Now let's really feed the troll:

And, please do not tell people with practical problems 
that they are free to use another wm.  What you are 
telling is in fact that peoples without a 2Ghz 
Redhat pc on their desk are not real users (!) and 
do not interest you.

By the way, I though that the idea behind metacity was to
have a lightweight wm. Without wirefame move/resize it 
becomes a big piece of bloat for us, non real users.
For non opaque move/resive, you have achieved what you are
criticizing about the old Nautilus: a fancy and bloated

Somehow, I also understand your position. You try to limit 
the functionnalities in order to keep the UI and the code 
as simple as possible. I have to admit that metacity 
features are usually well designed and that the code is 
really clean.

But systematicaly refusing new features because they would 
require a new config option is as bad as systematically adding 
new features in Sawfish. If you don't change your position
on the config options, I wouldn't be surprised to see a 
fork of metacity soon. As I mentionned before, your code is 
so clean that it it would be easy for any (non-real) programmer 
to fork and to start adding new features.

Comment 7 Havoc Pennington 2002-10-25 15:09:02 UTC
Note, I did NOT say no to the wireframe. You didn't read what I said. 

I said we need to analyze the real performance problems first, 
understand exactly what they are, and come to the conclusion that 
wireframe is the best/only solution, or at least all we can think of.
Which has NOT been done.

For all we know, the resize problems are all the fault of nautilus,
or all the fault of the bug about slow pixmap themes, or caused 
by the damage region pushing pixels on a SunRay which would be 
unchanged by wireframe. For all we know we could fix it using rate
limiting or other methods. The nautilus example is a *strong* argument 
for optimize first, add extra codepaths later. For all I know, 
we call XSync() 600 times per second during opaque resize
and that's the problem.

Convincing me to add wireframe is about *providing these facts* not
about rants. Rants just make me annoyed that people can't be bothered 
to justify their proposals or fix problems properly so they force
said fixage on the user.

And for the record, the opaque resize is *fine* on my 233 or 300 Mhz 
piece of junk laptop. We aren't talking 2Ghz here. We're talking 
total piece of junk laptop.

All I ever ask on a preference (or any feature) is *a compelling
argument*. Bust out the evidence. Bust out the pros and cons of
various approaches.

If you don't have that to offer, get off my bugzilla reports.
Comment 8 Stephane Chauveau 2002-10-25 16:25:21 UTC
> Note, I did NOT say no to the wireframe. You didn't read 
> what I said. 

You did not say no but I have a 'deja vu' feeling that you
are trying to trying to escape the wireframe mode by all 
means. By blaming 

> For all we know, the resize problems are all the fault 
> of nautilus, or all the fault of the bug about slow 
> pixmap themes.

No! You are still focussing on Nautilus. Any application 
can be slow to resize over a remote display. I am not 
using Nautilus but I also want faster display for example,
for Mozilla or the gimp. We are talking here about a factor
in term of redraw time between solid and wireframe. Even 
an Xterm can be slow to resize with a bad network connection.

> For all we know we could fix it using rate limiting or 
> other methods

Having a wireframe does not mean that you cannot also improve 
the opaque mode. 

> Convincing me to add wireframe is about *providing these facts* not
> about rants. Rants just make me annoyed that people can't be
> bothered to justify their proposals or fix problems properly so 
> they force said fixage on the user.

Facts? Ok!
(1) Redraw events can expensive. 
(2) The window manager has no way to know how much time a 
    redraw event will take. As single redraw of 10x10 pixels 
>  We aren't talking 2Ghz here.
The troll was really too big :-)

Comment 9 Stephane Chauveau 2002-10-25 16:49:23 UTC
Arghhh! I hate the tab key in Mozilla!

(2-suite) A single redraw in an unknown application may 
          take a few seconds.
(3) a wireframe move/resize do not have to send redraw events. 
  I think that wireframe are implemented by grabing the 
  display and using XOR lines. 
(4) an opaque move/resize has to send at least a few redraw 

Now, if having a new configuration for wireframe/opaque is 
really what is bothering you then I may have a idea.
Implement a single configuration to specify the efficiency 
of the display. The possible levels could be something like:

   Very Slow

Each feature with a potential impact on the performances would 
be disabled under a certain level. For example

  - Opaque move/resize would be replaced by wireframe 
    at level <= 'slow' 
  - Gradients in themes could be replaced by plain 
    colors at level "very slow'.
  - Animations in themes (If you implement some) 
    would be enabled at level >= "fast"


Comment 10 Brian Cameron 2002-10-30 11:50:38 UTC
A few comments.

1. I'd like to point out that bug 95802 discusses that metacity
   spends a lot of time resizing pixmaps when resizing windows.
   This would obviously be completely avoided by moving as wireframe.

2. On the render@XFree86.Org mailing list I noticed Owen Taylor 
   said the following in response to a person who mentioned that
   applications writers don't generally write their apps to be able
   to repaint in 10-20ms (the amount of time mouse move events 
   happen during a typical window resize event in X):

   If you imagine something like an opaque resize of a text widget,
   you can see why 10-20ms can be very demanding ... resizing a
   window 1 pixel wider might involve a complete relayout of a
   megabyte of text.

   Now, by using techniques like incremental layout, you can hide
   that relayout time, but that requires complex application design
   and a high level of sophistication.
Comment 11 Stephane Chauveau 2002-10-30 22:39:07 UTC
I do not consider your first point to be critical because
peoples with real performance issues can always choose 
a metacity theme without pixmaps. Repainting the applications
is the real problem here and there is not a lot we can do 
to improve existing applications.

Note that most metacity themes use gradients. To my knownledge
X11 do not provide any gradient primitives (in RENDER maybe?) 
so they are probably rendered offscreen in a pixmap/pixbuf. 

On my corporate network I have installed a modified version of
'Atlanta' in which the title gradient is replaced by a solid box.

I was hoping to find a nice solution with the svg library but 
the rendering can only be done offscreen in a pixbuf (the
documentation for the svg library is almost inexistant so I may 
have missed something)

Comment 12 Erwann Chenede 2002-10-31 17:25:10 UTC
Disclaimer : I was asked to implement this to try improving perceived
performance on Sunray systems. So don't shoot me for this patch ;)


Here is some related information :

Have a look at
for a discussion about this somewhat related subject.
Some work could be done it checking timestamps and discarding some of
them for
window move/resize.
But the main problem with remote X is that window that have a complex
rendering routines will always lag for the mouse/keyboard move-resize
as you have :
- WM move-resize window (worst case move of 1 pixel)
- APP recalculate layout (could be few seconds for complex word
processing apps or image rendering)
 then push pixels (which are almost the same) this is the killer for
remote X (one idea would be to compress
 the pixel pushed better...).
- loop...

Also note that each time it loops the lag will be worse as the
previous resize/move event won't have had
time to be processed by the app, resulting in a messed up display for
few seconds even after the resize finished.

So you could say all the application should be smarter and do
efficient redraw but this is
just no feasible (because of work involved and access limitation to
proprietary apps).

At the moment I only see two ways of improving this :-
- wireframe move/resize ( almost no pixel pushed (except from size popup))
- screenshot resize (e.g. take a screenshot of the app or draw an
opaque colored rectangle on top of the
 app (hide app) and resize this placebo instead of the real app).

The second option is just a more sophiticated wireframe move/resize
implementation which would be slower anyway. 


The attached patch sets the wireframe move/resize gconf key to false 
by default.
Comment 13 Erwann Chenede 2002-10-31 17:26:03 UTC
Created attachment 11936 [details] [review]
proposed patch
Comment 14 Havoc Pennington 2002-10-31 18:00:12 UTC
If you apply a patch that adds a preference in sun-patches, please
name the gconf key /apps/metacity/sun_extensions/whatever, or I
reserve the right to, say, create my own preference with the same name
as yours and different semantics. ;-)

The patch has some formatting issues:

 foo ()


 void foo ()


What proprietary (or Sun-developed or GNOME-developed) apps are
causing the problem, and how much of a problem are they causing?
Any apps I can try out myself?

Doesn't wireframe still push pixels on SunRay?
Comment 15 Stephane Chauveau 2002-10-31 20:26:11 UTC
> Any apps I can try out myself?
Find a remote display with a ping > 15ms. Then I guess that
opaque move/resize is a problem for almost X11 applications 
known by men.

If you don't have access to a remote display then take 
a program like mozilla and disable the acceleration of your
graphic card. 

> Doesn't wireframe still push pixels on SunRay?

I hope for Sun that a SunRay is capable of XORing 
a few dozen rectangles each second :-)

Comment 16 Havoc Pennington 2002-10-31 20:40:56 UTC
> I hope for Sun that a SunRay is capable of XORing 
> a few dozen rectangles each second :-)

As I understand it, SunRay isn't an X terminal, it's a remote
framebuffer device. i.e. it pushes the whole damage region, 
not a DrawRectangle request.
Comment 17 Stephane Chauveau 2002-10-31 21:41:37 UTC
Interesting! I couldn't find any relevant technical 
information about the technology on the Sun web site. 
I will have a closer look to this beast.

btw the patch works fine on my local desktop (I still 
have to test it with a remote display)

I have 2 remarks:

(1) The patch should grab the screen because the 
frame leaves some dirty traces when the background 
is modified between 2 consecutive XOR rectangles.

(2) The wireframe is not very visible.

In sawfish and fvwm2, the wireframe is a regular 3x3 grid.

I also remember a wm using a single rectangle composed of 
large dashed lines. The pattern was animated to create a 
'marching ants effect' link the selections in Gimp. Nice 
but probably more expensive than the 3x3 grid.

If the SunRay is not efficient to update large empty 
rectangles then you try to could draw only the corners.

Comment 18 Stephane Chauveau 2002-10-31 22:13:40 UTC
Havoc. Do you plan to integrate this patch?  

If you do not like this new key, could you make it 
available using another method (env var, compilation 
option, ...)?

btw. do you know when can we expect the next metacity release?

Comment 19 Havoc Pennington 2002-11-01 03:57:08 UTC
> Havoc. Do you plan to integrate this patch?  

I don't know. Probably something like it eventually.
I'm not happy about it though and I'm disappointed people
aren't willing to work to come up with a better answer.

> If you do not like this new key, could you make it 
> available using another method (env var, compilation 
> option, ...)?

If it exists I have no problem with it being a gconf key. 
My point about sun_extensions is just that I don't want
gconf keys in my namespace that I don't know about, that's 
bad in the same way that adding vendor-specific API to GTK would be bad.

> btw. do you know when can we expect the next metacity release?

I just put out a release the other day.

Comment 20 Stephane Chauveau 2002-11-01 17:32:13 UTC
> I'm not happy about it though and I'm disappointed people
> aren't willing to work to come up with a better answer.

I do not see what your problem is with wireframe. This is 
simple and efficient. Drawing a few rectangles cost almost 
nothing in term of cpu, graphic and network resources.
You can always try to optimize it but there is almost nothing 
to gain (and there is no real point to try). Of course, 
this is graphically uggly but we the primary goal of using 
wireframe is efficiency. 

That does not mean that opaque move/resize cannot be optimized
but in the worst cases, we are talking here about a efficiency 
factor of maybe 100 to 1000 between the 2 methods. Even if you 
optimize opaque moves/resizes by a factor 10 then this is still 
far from being acceptable and some peoples will prefer wireframe. 

As mentionned in some comments above, the only relistic way 
to achieve a real breakthrough in opaque move/resize would 
be to rewrite all applications or to change the X protocol. 

And to conclude this part I want to remind you that this 
bug is not about optimizing opaque move/resize. This bug 
is about optimizing move/resize on remote display. 
Wireframe does that very well. 

> My point about sun_extensions is just that I don't want
> gconf keys in my namespace that I don't know about, that's 
> bad in the same way that adding vendor-specific API to GTK 
> would be bad.

Humm. If they provide a patch then they expect it to be included
in the main development tree. In that case, this patch and the key 
are not anymore a vendor specific extension. But I agree with 
your point of view for patches that would be not integrated in 
the main dev tree (or patches that would be integrated but 
would not be compiled in by default)

> I just put out a release the other day.

Cool! thanks.

Comment 21 Erwann Chenede 2002-11-02 07:04:20 UTC
>If you apply a patch that adds a preference in sun-patches, please
>name the gconf key /apps/metacity/sun_extensions/whatever, or I
>reserve the right to, say, create my own preference with the same name
>as yours and different semantics. ;-)

Understood :), This patch is only meant for Sun's performance test atm
not for delivery. I only thought people could be interested to 
have a look (I guess I was wrong).
I'll make the appropriate changes hopefully next week 
(indentation and gconf key naming) and attach it.

>> Havoc. Do you plan to integrate this patch?  

>I don't know. Probably something like it eventually.
>I'm not happy about it though and I'm disappointed people
>aren't willing to work to come up with a better answer.

This is part of the Sun performance team work atm, they just 
wanted to have the possibility to test an alternative soluation at 
the same time I believe.

>As I understand it, SunRay isn't an X terminal, it's a remote
>framebuffer device. i.e. it pushes the whole damage region, 
>not a DrawRectangle request.

I guess this will be part of the tests the performance team will run.

[once again please don't shoot the messager]

Comment 22 Brian Cameron 2002-11-05 14:33:39 UTC

Bob Doolittle from the SunRay team had this comment in order to 
help everyone understand how SunRay's work...

> If you'd like to correct people about the basic capabilities of
> Sun Ray, you might point them to
> This is a somewhat out-of-date description of the basic rendering
> architecture and primitives of Sun Ray.  As described
> in this paper the basic primatives are SET, BITMAP, FILL, COPY,
> and CSCS (basically a highly compressed pixmap set operation
> useful for real-world images (such as video)).  In this paper
> Brian calls the protocol "SLIM".  We refer to it as "ALP" -
> Appliance Link Protocol.  Just in case you hear the acronym in
> future :-).
Comment 23 Joe Krahn 2002-11-06 04:33:40 UTC
I think the problems associated with opaque resizing are not
really a window manager issue, but an ICCCM/XEvent protocol issue.
Havoc is right that opaque resizing shouldn't be disabled just
because some apps or situations don't work with it. Instead, we
need to fix those situations.

Most of the rendering issues should be handled by the application,
but I think it would be good if there were a way to distinguish
an "active" resize event versus a final resize. This would enable
applications to skip certain complex rendering parts until the
resize is complete (i.e. the main display in a complex 3D app).
Applications could also ignore a resize if it comes too soon, but
still respond quickly to the final resize event.

Personally, I prefer not to use opaque resizing, and think it should
be an option. But, for it to be an option, we have to make sure
opaque resize works.
Comment 24 peter.kievits 2002-11-15 13:44:05 UTC
Created attachment 12321 [details]
additional info about the need for wireframe resizing
Comment 25 Stephane Chauveau 2002-11-15 17:36:42 UTC
Excuse him. This is his 1st post in buzilla :-) 
This is the message he attached: 

I would like to briefly jump into the discussion here and
point out that the application that Stephane C. has trouble 
with is commercial software for developing silicon chips.
This tool can potentially draw an awful lot of graphical 
elements (the chip layout) which easily takes several 
seconds over a LAN network, and can take a lot longer. It 
also wants to redraw the window contents when it is resized. 
You can understand that it quickly becomes unusable if during 
the resize it has to refresh several times. We really like to 
use Gnome+metacity as our desktop, but it should not slow down
our work. And unfortunately we have no alternative for the
software we're using ...

Comment 26 Erwann Chenede 2002-11-25 14:41:36 UTC
Attached is an updated patch which implement wireframe move/resize
as requested by Havoc, which creates a new namespace for the gconf
key wireframe_move_resize in /apps/metacity/sun_extensions
Comment 27 Erwann Chenede 2002-11-25 14:43:51 UTC
Created attachment 12540 [details] [review]
updated patch
Comment 28 Brian Cameron 2002-11-26 14:58:34 UTC
Tom O'Neill from the Sun WanRay team (a team that focuses on running
remote displays over slow-speed bandwidth connections, such as 56k
or 380k) pointed out that wireframe moves speeds dragging a window
across an RGB image (e.g., a JPEG on Netscape).

Also, the general reaction at Sun is that moving/resizing windows
with wireframe makes Gnome much snappier, and most users end up
turning on this feature.

We are currently working to generate some statistics that show
more measurably what performance improvements are gained by
wireframe move/resize.
Comment 29 Carsten Menke 2003-01-06 03:04:20 UTC
Jumping late into this Discussion but I hope it's not too late. I was
searching the whole time for this feature, and I think thoug it
needn't to be in the gneral preferences setting. It would be ok for
all, that it is just a gconf key. The unexperienced user will not
stumble over the setting not knowing what is meant by it. And the
expierenced user has yet the power to turn it on.

Really, I have 900Mhz and had always in favor of performance turned
this feature on in Gnome-1.4.

BTW, I have metacity-2.4.8 installed and can not find the
apps/metacity/sun_extensions key.

I would be really thankfull if this feature would be implemented
Comment 30 dserodio 2003-02-11 18:41:11 UTC
Would someone mind updating this patch for 2.4.34? I can't apply it to
this version, which AFAIK is the latest. Thanks a lot.
Comment 31 nos 2003-03-12 10:15:23 UTC
Lack of wireframe resizing/moving made me swithch to KDE right away
when I first installed RH 8.0, a slow desktop is the worst I can
imagine.. I'd be much happier with wireframe only.
Will wireframe eventually be implemeted ?
Comment 32 Murray Cumming 2003-03-14 07:54:38 UTC
Added PATCH keyword.
Comment 33 Christian Rose 2003-03-14 20:47:09 UTC
Adding string keyword.
Comment 34 Rob Adams 2003-03-16 00:25:19 UTC
Unfortunately, it looks like this is a genuine problem that we can't
solve without adding a preference.  What I'd really like to see is
some technique that would allow us to benchmark a server as we start
up, but I don't think that it's practical.

I think that with this issue the preference is the best way to deal
with it.
Comment 35 Chad Miller 2003-04-25 04:14:04 UTC
Suppose that box/"wireframe" was the default and someone offered a
patch to metacity to do opaque moving.  What would we say?  Would it
pass the no-crackrock test?

Arguments for implementing opaque moves:
 * Less surprising than wireframe-move for someone who has never moved
a wireframe before.  (strong)
 * Pretty on very fast-updating hardware.  (very weak)
 * One can visually align a window based on its content.  (weak,
rarely useful)

Args for "keeping" the box-moving:
 * At least as fast as opaque, and often much, much faster.  (strong)
 * Not surprising after the first experience of moving.  (weak)

I would probaby reject a opaque-movement patch as eye-candy.  The
surprise factor will only be relevant once, but the speed improvements
of wireframe-movements will pay off many, many times per session.

I don't have numbers to support my assertion that wireframe movement
is faster than opaque.  I do know that it's one of the first things I
turn off in any windowing environment I use, because it's noticably
slower.  Moving windows is not real work; it's a distraction from the
reason you're really at a computer, so we are _much_ more sensitive to
perceived slowness in fixing when the desktop metaphor starts to wear
thin and we have to shuffle windows around.  When you have to switch
contexts to window-management mode, even an extra 1/10th of a second
of watching useless animation is irritating because your brain really
wants to get back to the previous context.


Wireframe implementation ideas:

How might we minimize the movement-metaphor breakage and keep the
wireframe visually associated with the window?  I'd connect the
corners of the wireframe with the corners of the source window
position, so it's more obvious what one is moving and where.  Perhaps
it would be better to make the connecting lines appear only if the
window is being moved more than some distance, like half of the
window's width or height.
Comment 36 Chad Miller 2003-04-25 04:26:11 UTC
In case my position was vague, I advocate _removing_ the opaque
move/resize altogether and replacing it with wireframe movement with
source window hints.  I don't think anyone needs opaque movement, or
an option for it.
Comment 37 Havoc Pennington 2003-04-25 06:54:19 UTC
The argument for opaque is direct manipulation: you're manipulating
the object on the screen. Wireframe means you can't see the window
contents as you resize, so if you're say resizing to be able to see
all of a document, you can't tell whether you're getting the right
size. And there's a mental abstraction to compute to connect the
wireframe with the window it replaced.

OS X I'm pretty sure has opaque resize only, and Windows XP defaults
to it. Both of those systems are based on significant user testing, 
and both are fast enough.

Note also that a slightly post-GNOME-2.2 nautilus will be much faster
at drawing areas of the desktop background that don't have icons on
them, which impacts overall system load while resizing.

The opaque is fast enough on my 266 mhz laptop. Also, CVS version of
metacity was easily made faster by Soeren as soon as he did some
profiling; and we have an outstanding GTK patch to make it smoother.
Those are fixes we already have ready to go for GNOME 2.4. 

I would expect that with more profiling and thought there are a number
of additional speedups possible.

Another thing we can still do is implement double buffering in the X
server that spans both frame and client to avoid the tearing/flicker
effect as you opaque resize.

Honestly though I think my big hangup here is that I just don't see
the speed problem on my system. I don't know if it's because I use a
simple WM and GTK theme, or because I use a simple desktop background, 
or what. My computers are not especially high-powered or fast, but 
if I resize a window it tracks the mouse with no significant lag.

If I had a better understanding of when it was slow or why or what
code was slow, it would be easier to address the issue.
Comment 38 Havoc Pennington 2003-04-25 06:57:54 UTC
It would be interesting to analyze opaque resize using the tools from:
Comment 39 Toni Willberg 2003-05-20 12:21:01 UTC
I'm running RH8/9/rawhide on AMD 1600-1800+ with
radeon7000/radeon7500/mga200 video cards and window moving/resizing is
way too slow on all those systems with Metacity.

Earlier RedHat used Sawfish which was like from other planet when it
comes to performance.

Opaque drawing is just waste of (cpu)time for me.
Comment 40 patrick largey 2003-07-13 18:50:48 UTC
Perhaps with the mail from Alan C, you can understand ......

But i hope no more :-(

Comment 41 Havoc Pennington 2003-07-13 19:02:25 UTC
Rationale makes changes, whining does not.

I tried opaque resize on a SunRay thin client at GUADEC - not slow.
Not slow on 266mhz laptop. Windows XP defaults to opaque. OS X only
has opaque.

I'm thinking of adding the wireframe because it's in two vendor 
patches anyway, and because some proprietary apps can't handle 
opaque resize properly.

But blowing things out of proportion is just silly.
Comment 42 Havoc Pennington 2003-07-23 21:42:49 UTC
Created attachment 18554 [details] [review]
Proposed patch for "reduced resources" mode
Comment 43 Brian Cunnie 2003-07-23 23:20:36 UTC
Hello Havoc and everyone,

I want to thank you Havoc for addressing this issue (slow redraw for
opaque resize for certain apps).  We have seen this problem at my
company (Aeluros) where we design chips using Cadence's Analog Artist.

Specifically when we try to resize certain windows (usually fairly
complex signal graphs) it takes on the order of seconds for the window
to stabilize.

The system we are using is 1.666GHz Athlon, Nvidia GEForce2, 512MB
RAM, RH9.  The application is purely local (i.e. network traffic is
not the bottleneck).

One of your suggestions--using another window manager--is our
temporary solution; we use fvwm2 as well as gnome currently.  The
designers would prefer to have a pure gnome environment but are okay
with switching between fvwm2 & gnome/metacity.

We would like Cadence to address the issue but we doubt that will
happen in the foreseeable future; Cadence tends to be on the trailing
edge (e.g. they only officially support redhat 7.2 and 7.3).  And
Linux is new for them (they run on Solaris, HPUX, and AIX).

Which is why I (and the designers here) are grateful that you are
addressing it; we'd rather run on linux than solaris, rather gnome
than fvwm2.


Comment 44 Havoc Pennington 2003-07-24 04:16:13 UTC
Right, the argument that finally convinced me we needed to do this 
was the large number of proprietary apps that just fall over if they 
get a lot of configure events. Cadence, Landmark, all kinds of things.
Hopefully the default of opaque will be enough to get the apps 
fixed eventually.

I did it as a reduced_resources = true flag though because I think
there may be nicer visual effects than wireframe that get the same
advantages, perhaps just blanking out the application contents, but
still displaying the window manager frame, or something like that.
Someone told me that Windows could do this, don't know if it's true.
Also this lets us load other kinds of performance-related tweaks onto
a single setting.

The wireframe stuff does indeed make a big mess all over the source
code, and has some minor not-quite-rightness (the wireframe doesn't 
obey window size constraints for example), so I don't love the patch
but it's workable. 

The patch is based on Erwann's patch so he gets a lot of the credit.
Comment 45 Rob Adams 2003-07-24 14:36:47 UTC
obviously this is a 2.6 patch.

I have very serious reservations about introducing a
move/resize/whatever method that doesn't obey size and position
constraints.  This should definitely not appear in a stable metacity
unless this is fixed.

I do like the idea of perhaps showing only the window frame -- this
avoids the problems with craptastic apps while also not creating the
weirdness of wireframe mode.  We should experiment with that.
Comment 46 Havoc Pennington 2003-07-28 00:06:21 UTC
Right, it's a GNOME 2.6 patch. Thus the branch. ;-)
I will probably land it in Red Hat before that though.

The window resizing still obeys constraints, just the wireframe feedback 
doesn't. So your window doesn't end up exactly where the wireframe
indicates. This is sufficiently painful to fix, and the Sun patch has 
the same bug, that I'm awfully inclined to just not care.

I'm all for experimenting with less-sucky approaches, 
as the wireframe is so early-90s looking.

The basic problem with the constraints stuff is that even if you 
hide the app window, you can't send it configure events, because
I'm sure these busted apps aren't sophisticated about whether 
they're actually visible during the resize. I'm very reluctant to 
extend hacks deep into all the window resize and constraint code 
to handle the window not actually being resized...
Comment 47 Havoc Pennington 2003-07-29 16:11:04 UTC
Created attachment 18722 [details] [review]
Backport to GNOME 2.2
Comment 48 Havoc Pennington 2003-08-10 14:29:58 UTC
*** Bug 119554 has been marked as a duplicate of this bug. ***
Comment 49 Baptiste Mille-Mathias 2003-08-11 04:11:07 UTC
*** Bug 119607 has been marked as a duplicate of this bug. ***
Comment 50 Havoc Pennington 2003-08-11 22:28:05 UTC
punting to 2.5 branch
Comment 51 Rob Adams 2003-09-01 14:40:54 UTC
*** Bug 121177 has been marked as a duplicate of this bug. ***
Comment 52 Rob Adams 2003-09-22 17:22:09 UTC
*** Bug 122896 has been marked as a duplicate of this bug. ***
Comment 53 Havoc Pennington 2003-09-25 01:00:55 UTC
This is just a matter of merging back the branch (I think the attached
patch has all the branch changes, so could just apply the attached
patch). Can do as soon as we have an unstable branch.
Comment 54 mystilleef 2003-10-02 17:34:53 UTC

I  use GNOME-2.4/metacity-2.6.1. I assumed the option to enable
wireframe would be in this version of metacity. I searched for it via
the gconf editor, but to no avail. I've also asked several individuals
on the gnome IRC channel and again noone could help me with it. I'd
like to know if this option is available for this version of metacity
and if so, where I can enable this feature. 

Comment 55 Rob Adams 2003-10-02 17:37:41 UTC
sure; just apply the "proposed patch for "reduced resources" mode"
patch to metacity source and compile it.
Comment 56 Havoc Pennington 2003-10-12 06:25:59 UTC
Patch applied to HEAD, will be in GNOME 2.6
Comment 57 Elijah Newren 2004-02-18 01:12:53 UTC
*** Bug 134656 has been marked as a duplicate of this bug. ***