Hi all

During the latest emerge -DuNv world KDE SC 4.8.0 was pulled in (Gentoo ~amd64).

Since then, windows always display/redraw their content when resizing/moving.

There used to be a setting in System Settings -> Window Behaviour -> Window Behaviour -> Moving that allowed to turn that off ("Show content when moving/resizing windows"), which resulted in the entries "ResizeMode" and "MoveMode" in ~/.kde4/share/config/kwinrc being set to "Transparent" instead of "Opaque".

This setting is gone now, and the ResizeMode and MoveMode settings are ignored (but still present in kwinrc).

Does anybody know if this is a transient feature dump (i.e. if there are plans to support this useful feature again)?

Or is there now a different way to achieve the same goal (i.e. NOT to constantly redraw the content in resizing/moving windows)?

I did see and activate the "Resize" desktop effect.
It is a rather poor replacement for the original options, though:
either it does not show the new size during resizing at all, or it draws a blueish area indicating the new size or it takes a kind of screenshot of the current window contents and scales it during resizing.


Thanks everyone

Markus

The option has been dropped (it derives from times when moving/resizing windows was to expensive, eg. because there was not even an X11 backing store)
The resize is an effect plugin, so theoretically one could write a effect plugin to mimic the legacy behavior.

If you're esp. interested in looking behind the window you're moving/resizing, the translucency effect provides such functionality.

Any particular further worries?

That's a pity. Becuause constantly redrawing the window content in a moving/resizing window is just a misuse of resources (and not even amusing
It has nothing to do with what background I personally want to see during resizing.

You are aware of the fact that there are older computers in use still, and that eg. netbooks do not have very powerful graphic chips?

regaleali wrote:That's a pity. Becuause constantly redrawing the window content in a moving/resizing window is just a misuse of resources (and not even amusing

and that's why it uses a sync protocol to not constantly redraw the window. Furthermore there is the resize effect which allows you to not redraw the window at all.

regaleali wrote:You are aware of the fact that there are older computers in use still, and that eg. netbooks do not have very powerful graphic chips?

which has nothing to do with it. Even older computers can use the XRender based compositing and use the resize effect.

Thanks for the feedback.

The resize effect imho is not a full replacement for the old behaviour. You can either have a scaling image map of the old content during resize, have no indication at all of the new size, or have a kind of blueish area around the original window when resizing it, indicating the new size. This third option is the more useful one, but it is really rather aggressive color- and handling-wise, covering the whole desktop with a semi-transparent, single color area during resize. I think the old behaviour (just redraw the window border) was much more sensible and less intrusive. And maybe it's just that after many years in front of a computer screen, I have become used to window borders being moved during resize, not afterwards.

And, of course, the resize effect only affects resize, not move. Currently, on my i7 (2 cores/4 threads ea.), CPU usage rises by up to 20% when I move a window around the desktop. Beside the window content, also the background needs to be constantly redrawn.

Composited moving should have about zip overhead compared to non visualized moving.
The expensive part on the CPU are rather all the sanity & snapping checks - and it's basically sucking as much CPU as you have corresponding to the move speed.
The "limiting" factor for composited move repaints is more the memory throughput, that should not be an issue for even "older" ie. eg. AGP based systems (maybe for 2MB V7 PCI cards, though

For uncomposited moving (an uncomposited environment in general) i /strongly/ recommend to attempt to reactivate the BackingStore (an /etc/X11/xorg.conf option) since it's meanwhile defaulted off because of the compositors around.
This -if still supporte by your driver- will vastly reduce the exposure events, thus client repaints.

Since the issue however seems more of the aesthetic nature, this
"The resize is an effect plugin, so theoretically one could write a effect plugin to mimic the legacy behavior."
still holds - one could certainly adapt or incorporate eg. the outline effect which however -depending on the plasma theme- actually can look pretty weird either ;-P

Hi; i would like to say that i also miss the option for Show content when moving/resizing windows ==> "MoveMode=Transparent" "ResizeMode=Transparent"

This ist not the question only for local GPU resource. This option can be very useful for remonte desktop like X Terminal or NX Client!

I think that composite effect not really usable for use on the Remote Desktop

P*

+1 "MoveMode=Transparent" "ResizeMode=Transparent"

And +1 this same setting.

When working with nomachine or x2go that makes a big diference.

What the hell, even windows 2008 has that option to remote desktop users. The fact is that any nx client will have to redraw the are below the window

for the records, and pure information - i'm not available for discussion on this topic (no strong opinion and not in charge to decide either):

if you activate the resize effect in the "all effects" section (whether you select outline, resize or both is irrelevant) there will be no resize events sent down to the client, nor extra Xsync(False) calls, ie. in that case you actually do have the "transparent" feature.

If you're running kwin on a remote machine, you got different issues (starting with the oxygen decoration, ending with the Qt default raster graphicssystem)

So the only real problem is, if you do not use compositing on the local machine, what needs explanation (given the absence of the backingstore in many servers and virtually all default setups)

I use KDE remotely via NX. Desktop effects aren't available to me, and it doesn't seem like I can avoid showing window contents while moving or resizing windows. For me, the usability of KDE is significantly compromised by the absence of this single feature. Actually I think I'll need to use a different window manager, unless there's a solution I'm missing here.

vonkruel wrote:I use KDE remotely via NX. Desktop effects aren't available to me, and it doesn't seem like I can avoid showing window contents while moving or resizing windows. For me, the usability of KDE is significantly compromised by the absence of this single feature. Actually I think I'll need to use a different window manager, unless there's a solution I'm missing here.

Till now i couldn't find a solution.
I guess that you will have to submit a wish request to kde developers

vonkruel wrote:I use KDE remotely via NX.

don't do that. A modern environment is just not optimized for that use case any more as you can see in this issue and also in all the issues mentioned in Thomas's post.

If you need to run a full blown session better use technologies which are optimized for it like krdc/krfb. If you are only interested in some windows just forward them.

mgraesslin wrote:

vonkruel wrote:I use KDE remotely via NX.

don't do that. A modern environment is just not optimized for that use case any more as you can see in this issue and also in all the issues mentioned in Thomas's post.

If you need to run a full blown session better use technologies which are optimized for it like krdc/krfb. If you are only interested in some windows just forward them.

I guess we are not talking about the grandmas PC or the son laptop here running latest kde supra new technology.

i was talking about running KDE as a DaaS, and if you want to deploy KDE to your customers or inside your organization securely over the internet you surelly will not use krfb

In the kde 3 times, kde developers had a completly different vision from the people that are there now, maybe that's why kde trinity desktop fork makes sense.

just my 2 cents.

hteles wrote:I guess we are not talking about the grandmas PC or the son laptop here running latest kde supra new technology.

Then I do not know what we talk about. Enterprise distributions are still using 4.3 or 4.4, not the "supra new technology" which doesn't ship that feature any more.

hteles wrote:i was talking about running KDE as a DaaS, and if you want to deploy KDE to your customers or inside your organization securely over the internet you surelly will not use krfb

so RHEL or SLED, running 4.3 or even 3.5, so where exactly is the problem?

hteles wrote:In the kde 3 times, kde developers had a completly different vision from the people that are there now, maybe that's why kde trinity desktop fork makes sense.

Right and enterprise systems will use the high quality system produced by 14 developers thinking they can maintain a few million lines of code.

To be quite clear: so far I have not seen any complaint by an enterprise and I'm quite sure that RedHat developers or SUSE developers know how to reach us. And I'm even more sure that we would find a solution for them if they need this feature.

Having a very rare feature which is broken in the default setup combined with a default setup which makes it hardly possible to run a remote system in the first place (note: not KDE's fault) does not make any sense. Even if there is a handful of people who would like to have it. We need to keep more in mind than making all users happy - that is just not possible.

Btw. it's also possible to switch to a different window manager in a remote session.