Q: Xserver / Composite behavior

[Russell Shaw]

Friedrich W. H. Kossebau wrote:
> 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?

Probably not. You'd see 2D projection views of complex underlying 3D objects.

If you have a computer generated shape such as a pyramid, very little
memory is used to store it (just a few coordinates and colours etc).
The high-res bitmap on the screen is generated on demand by the card.

Only if you had highly complex objects (such as detailed polygon constructions)
would much memory be used, but probably never in the MB range for a full screen.
Detailed textures (gives surface coloration) can use lots of memory just like
a bitmap.

The biggest waste of memory is crappy simple 2D widgets that have double buffering
enabled by default. This could easily happen if you have many word-processor
documents open.

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

Only for double-buffered widgets, which is up to the implementor of the
widget toolkit used.

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

I don't even know what people mean by "thumbnails". They're just small images?

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