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 ***

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?

(aside: did you mean to reopen the bug this was a dup of, instead of 
this bug?)

<lecture>
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 
codepaths.

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.
</lecture>

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.

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.

*** Bug 96182 has been marked as a duplicate of this bug. ***

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

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.


 

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.

> 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 
an 
 
>  We aren't talking 2Ghz here.
The troll was really too big :-)

Arghhh! I hate the tab key in Mozilla!

Facts:
(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 
    events. 

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:

   Fast 
   Normal
   Slow 
   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"
   etc...





 

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.

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)

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
http://www.xfree86.org/pipermail/render/2002-October/002041.html
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
layer/layout
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.

Created attachment 11936 [details] [review]
proposed patch

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:

 void
 foo ()

not 

 void foo ()

etc.

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?

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

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

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.
 

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?

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

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

>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]

FYI-

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
>
> http://www-suif.stanford.edu/~bks/publications/sosp_slim.pdf
>
> 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 :-).

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.

Created attachment 12321 [details]
additional info about the need for wireframe resizing

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

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

Created attachment 12540 [details] [review]
updated patch

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.

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

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.

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 ?

Added PATCH keyword.

Adding string keyword.

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.

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.

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.

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.

It would be interesting to analyze opaque resize using the tools from: 
http://keithp.com/~keithp/talks/usenix2003/

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.

Perhaps with the mail from Alan C, you can understand ......

http://www.gnomedesktop.org/article.php?sid=1213&mode=thread&order=0

But i hope no more :-(

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.

Created attachment 18554 [details] [review]
Proposed patch for "reduced resources" mode

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.

Thanks,

Brian

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.

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.

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

Created attachment 18722 [details] [review]
Backport to GNOME 2.2

*** Bug 119554 has been marked as a duplicate of this bug. ***

*** Bug 119607 has been marked as a duplicate of this bug. ***

punting to 2.5 branch

*** Bug 121177 has been marked as a duplicate of this bug. ***

*** Bug 122896 has been marked as a duplicate of this bug. ***

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.

Hello,

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. 

Thanks

sure; just apply the "proposed patch for "reduced resources" mode"
patch to metacity source and compile it.

Patch applied to HEAD, will be in GNOME 2.6

*** Bug 134656 has been marked as a duplicate of this bug. ***