Q: Xserver / Composite behavior

[Friedrich W. H. Kossebau]

Hello,

allow my, thus an interested user's ignorant objection:

Am Sonntag, 8. Januar 2006 08:38, schrieb Carsten Haitzler:
> On Sun, 08 Jan 2006 12:34:05 +1100 Russell Shaw <rjshaw at netspace.net.au>
>
> babbled:
> > Keith Packard wrote:
> > > On Sun, 2006-01-08 at 01:46 +0100, Amir Bukhari wrote:
> > >>What happend when application move it's top level window out side root
> > >>window. Example: screen is 1200x1024 and a window is moved to 1600,512
> > >> which out side screen. Does Xserver will not alow it or it will only
> > >> not be visable?
> > >>does Xcomposite will stil render to off-screen pixmap?
> > >
> > > The entire contents of the redirected window are always available,
> > > independent of position or stacking.
> >
> > Isn't that a bit inefficient? If you had a 1000x1000 window scrolled
> > outside the root, it'd be wasting 4MB in a useless pixmap. No wonder
> > X is so slow;)
>
> then dont use compositing! :) seriously - the contents are NEEDED! without
> them you cannto do loive pager/icon thumbnails - things like "expose" in
> osx are not possible etc. etc. etc.

So those with a habit to keep 50+ windows open are doomed, then?

Question:
Are all and every windows' pixmap contents really kept completly in (graphics) 
memory?

If I take my currently opened windows and consider their content I see that 
they consist of mostly static and only some dynamic areas (animated adds in 
websites, monitoring views, etc.). Not all content will be mapped somewhere 
visible (unless I start to have all windows transparent what IMHO could not 
be sanely minded done). So I wonder if the composition cannot be optimized 
and take these details into consideration:

Decomposing windows into used and not used parts:
Windows are treated as group of visible(=used) and unvisible subwindows. Only 
visible subwindows are kept in memory. 

Caching thumbnails:
For live pagers/thumbnails/etc. which use downscaled window contents (instead 
of e.g. special views given by the window's program) it might make sense to 
cache the thumbnails of window( part)s with static content (in the biggest 
used thumbnail size).
Animated parts would be drawn in the part's full size offline and then mapped 
onto/composed with the static parts of the thumbnail for the display
If the program updates (parts of) the static content it would register a 
one-time "animated" area, draw to it and have it mapped. As such updates are 
usually done by doing doublebuffering the only technical difference would be 
that the mapping would not (only) go to the original content but also in a 
scaled version to the thumbnail.
Alright, some of the surrounding static pixels of animated/updated parts might 
be additionally needed for calculating the scaled border pixels but there 
could be a clever solution for this.

Vector-described window contents:
Is there a special treatment of such windows? They could be rendered on demand 
for a given size (aren't today's GPUs specialized on this?), see Cairo, Qt's 
Arthur, of course OpenGL views, etc. No need to keep large pixmaps around all 
the time, or? 

I guess this all might complicate things a little. But as memory is still a 
limited resource I guess some trade is needed. Most of this might not be 
applyable to legacy apps, but current gui toolkits could perhaps be prepared 
for such X features.
Or is something like this or better already considered? My shallow Google 
querying did not yield anything. 

So far some hopefully not annoying user-only's 2 cents/comments, thanks for 
reading/any answer :)

Regards
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060108/0e40db44/attachment.pgp>