Bug 3342 - Outlines for moving and resizing.
Status: RESOLVED WONTFIX
Alias:
Product: Openbox
Classification: Unclassified
Component: general
Version: unspecified
Hardware: PC Linux
: P4 enhancement
Assignee: Dana Jansens
QA Contact:
URL:
: 4809 5055 5507 6189
Depends on:
Blocks:
 
Reported: 2007-09-02 05:36 EDT by bdjnk
Modified: 2015-09-17 14:29:52 EDT
8 users (show)

See Also:


Description bdjnk 2007-09-02 05:36:57 EDT 
When windows are moved or resized in OpenBox, they are redrawn continually, and on a slow computer this is quite visually choppy and unappealing. Even with the drawContents option in the resize section of the rc document set to no, any graphics that are below the window being resized are still continually redrawn leading to the same ugly result.

What I propose, is that the window being manipulated should remain exactly as it is and an outline of the new window position or size should be created. This outline should be continually updated while it is being manipulated until the mouse button is released, at which point the window should be redrawn in the position of the outline.

This would look cleaner and take less resource (I would think). The "Update the window contents while resizing" option in ObConf could be replaced with a option to "Use outlines when moving or resizing windows".

I love using OpenBox and this would make it perfect.
Comment 1 Dana Jansens 2007-09-03 12:54:52 EDT 
using composite also makes things stop redrawing.  this has been requested a few times, but it doesn't seem very important as no one has cared to attempt any code for it still.   the one place this is truly useful is in a vnc-like environment, and those can do the move/resize in wireframe mode overriding the window manager.
Comment 2 A. Klitzing 2008-07-23 09:54:19 EDT 
I like to see this feature, too.
I prefer an "outlined box" like in compiz. It will show a blue (or another color) box over the window and you will resize only this blue box until the mouse button is released.

Example (the blue box should be over the window; it's a bug in compiz in that image):
http://lh3.ggpht.com/jack.un/RvjXCTBlXQI/AAAAAAAAATA/Q9V6Le6m5Ek/Kuvat%C3%B5mmis.png?imgmax=512

I don't like those "outlined lines" like in metacity. It's really ugly... ;-)
Maybe someone will find time for this. :-)
Comment 3 Dana Jansens 2011-08-30 12:31:44 EDT 
*** Bug 5055 has been marked as a duplicate of this bug. ***
Comment 4 Mikachu 2013-08-11 09:55:49 EDT 
*** Bug 5507 has been marked as a duplicate of this bug. ***
Comment 5 Mikachu 2013-08-11 09:59:21 EDT 
*** Bug 4809 has been marked as a duplicate of this bug. ***
Comment 6 Jérôme 2013-08-16 15:03:25 EDT 
Maybe it should be optionnal like the "drawContents" XML element of the "resize" element into the ~/.config/openbox configuration file.
Comment 7 Dana Jansens 2013-08-16 19:35:59 EDT 
In order to implement this, I think we need to make a set of windows like the focus cycling highlight and move that around, then kill them and move the window once the move is complete.
Comment 8 Mikachu 2013-08-17 04:48:29 EDT 
Moving a wireframe window around (as opposed to the XOR stuff) would use exactly the same amount of resources as, if not more than, just moving the actual window around. Eg, it would cause redraws of everything under it and additionally the window itself.
Comment 9 Dana Jansens 2013-08-17 11:47:58 EDT 
That's totally true, but the wireframe would at least cover fewer pixels up on the screen, and allow you to see where you're putting the window. Also if you move the wireframe a large number of pixels at a time, it would expose fewer pixels than a solid box would, which may be a visible difference on a latent connection where many move events can get coalesced.

I'm just not interested in the XOR thing, where we block all X applications on the machine during the move, that seems just silly.
Comment 10 loredan 2013-08-24 02:44:30 EDT 
The wireframe box feature is implemented in TWM. In general if one is using a slower machine that cannot handle Openbox's resource requirements one should switch to TWM. It has been around for ages too.
Comment 11 Luke 2014-04-01 20:05:02 EDT 
With support for Windows XP ending, it's important to get this feature implemented. I just tried to replace XP with Lubuntu on a P3 1Ghz, 512 MB, 64MB GeForce2 GTS. The machine ran XP fine, but window management performance is unacceptable in Lubuntu. The basic task of dragging windows results in 100% CPU usage and a long pause as the user has to wait for the window to arrive at its destination. 

Just telling people to use another windows manager is not an acceptable solution. TWM is a major downgrade from Openbox. If Openbox only supported this feature, it would be a perfect fit for XP era machines, without having to suffer with the restrictive TWM environment.
Comment 12 Mikachu 2014-06-23 09:31:21 EDT 
*** Bug 6189 has been marked as a duplicate of this bug. ***
Comment 13 loredan 2015-09-16 13:43:40 EDT 
Just posting to this very old thread to see if there has been any activity on this bug?
Comment 14 Dana Jansens 2015-09-17 14:02:02 EDT 
A better alternative these days is probably just using a compositing manager. Then moving a window around won't cause any exposes for other windows.
Comment 15 Mikachu 2015-09-17 14:29:52 EDT 
If they really see the window lagging as it moves toward the target, I doubt a compositing manager would help, or would even run. It's likely that they're using a software rendering driver with extremely slow blits. Just buy a new computer ;).