Resizing child windows

[Glynn Clements]

Carsten Haitzler (The Rasterman) wrote:

> > > > 	Needless to say, but apart from reducing flickering, an
> > > > 	application with windowless child widgets is much more
> > > > 	light-weight and resource friendly as we don-F-F-F’t allocate-A
> > > > native-A-A windows for every single widget.
> > > > 
> > > > It's only "resource friendly" if you ignore the overhead of processing
> > > > (as well as transmitting) all of those MotionNotify events.
> > > 
> > > that overhead is really nothing to worry about. for every time u need to
> > > reconfigure
> > 
> > How often is that? It's a lot less frequent than motion events.
> 
> its incredibly more expensive than a motion event by several digits in factor -
> and much more noticeable.

My point is that the cost doesn't matter for things which only happen
infrequently, and motion events are more common than configure events
by many orders of magnitude (it's common that windows are *never*
reconfigured after creation).

> > > for that matter
> > > non-rectangular event regions - see how wonderfully efficient x gets with
> > > window shapes having to be generated and set/reset from client to server
> > > side, instead of simply handling it with much more efficiency client-side.
> > 
> > How common are non-rectangular widgets? Beyond that, how common are
> > non-rectangular widgets which are non-rectangular for reasons which
> > aren't purely cosmetic?
> 
> it is purely cosmetic - but users LIKE IT. artists and designers LIKE IT. they
> are actually very common when you give the designers a chance to have some fun.

... which happens a bit too often for my liking. My computer isn't a
playground for designers, particularly for ones who favour form over
function.

However, I suspect that some users are willing to pay the price for
eye candy. I just wish they'd bugger off to Windows or OSX; some of us
have work to do. There was a time when Linux had an advantage over
Windows/OSX, arising from being driven by technical considerations
rather than marketing ones.

[FWIW, the reason I abandoned Athena was the lack of support for
keyboard traversal, not aesthetics.]

> > > once you
> > > get sufficiently exotic - x's event stream breaks down and you DIY. since
> > > the cost difference is really negligible (these days) you go for just 1
> > > model for simplicity. they are doing the right thing by their design and
> > > needs. zack isn't dumb by any stretch of the imagination and he knows his
> > > way around x.
> > 
> > It isn't the right thing by my needs. But then I do actually rely upon
> > network transparency quite heavily (my main X terminal is my WindowsXP
> > box; that *needs* a monitor, so it may as well be the one which gets
> > it, and thus acts as X terminal for everything else).
> 
> x is pretty horrid over the network, efficiency-wise. RDP is better. we don't
> even have any compression for image puts in any way or form. xlib itself can be
> quite round-trip heavy if you aren't careful. it's almost a moot point trying
> to be efficient over a network.

I managed to have X useable over dialup (28.8-56k) for many years, so
it isn't beyond the bounds of possibility.

Images aren't that significant unless the client is actually a
graphics program (which is always going to be problematic with a
remote connection), or is badly written (e.g. gratuitous and
non-optional use of images, repeated XPutImage() instead of a Pixmap,
use of 32-bpp images where a bitmap would suffice, ...).

What *is* significant is forcing the client to respond to a continuous
stream of events which could have been handled entirely by the X
server. You don't *have* to send every mouse movement back to the
client so that it can keep changing the cursor; the server can do that
(and won't suffer from latency).

-- 
Glynn Clements <glynn at gclements.plus.com>