Q: Xserver / Composite behavior

[Carsten Haitzler (The Rasterman)]

On Sun, 8 Jan 2006 13:13:13 +0100 "Friedrich W. H. Kossebau"
<Friedrich.W.H at kossebau.de> babbled:

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

pretty much - yes. sure a window manager WITH a composite manager CAN decide to
make exceptions (iconified windows it could stop redirection on, or windows it
knows have no visible miniatures visible anywhere), but in principle it needs
to keep them all around UNLESS some exception allows them to be removed.

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

in a compositing scenario - yes. every toplevel redirected window will have its
pixmaps in the xserver (in video ram, or if that runs out, system ram). so for
example - in 32bpp have 2 fullscreen windows - they will use 7.5mb each - if
you have 32mb video ram, opengl with dri tends to eat up half of the ram even
if u never use it - just to pre-allocate texture ram, so you have 16mb left.
7.5 mb will be needed for the framebuffer, so u have 8.5mb ram - 1 window will
fit in video ram, the other will be moved to system ram and all rendering on
this suddenly has to be done in software. so yes. it's as bad as it sounds.

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

but thats the point of compositing. 1. to allow smoother screen updates by
basically causing all draws to be double-buffered implicitly AND allowing the
compositing manager  to even syncronise and merge updates avoiding flicker.
that's life with compositing. :)

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

that's up to the compositing manager it COULd do some smart things as i
described above - IF that were the case. generally speaking it needs to work
hard to do this currently and a wm can currently manage this best as it can
force composite redirection when being managed and defer the mapping of the
managed window until it gets all damage events... but if that window is to be
used for expose - this gets bad as it doesnt have the pixel contents available
when needed etc. etc.

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

sure - but then how does it UPDATE the thumbail? it needs the source pixels to
read from. it won't have these UNLESS the program is already redirected. think
of it the same way as normal jpeg thumbnails. the source .jpg STILL exists. you
dont delete the original file. an app expects whatever it drew before to STILl
be there until it redraws. thats who immediate drawing mode works. expose
events indicate a damage, and otherwise the app can assume its window contents
were identical to the way they were before - except for regions exposed.

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

not really. as far as x knows the contents of a window are a set of NxM pixels
- that's it. it knows nothing more. so you can't really do this. sure x could
get smart in what it keeps in VIDEO ram - by dividng pixmaps into tiles and
only active tiles stay in video ram and inactive ones migrate off to system ram
- but they still must EXIST.

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

no. no special treatment. they are just pixels.

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

unfortunately for you (and others) a compositing display environment, by
definition, and nature, is HEAVY on video ram needs. like modern games with
lots of high-res textures. they just need LOTS of video ram. that's how it
works. sure - you can reduce the needs by not using textures - use flat
polygons, that will use much less video ram, BUT you give up textures. for
compositing - the requirement is to have ALL source pixels available for all
possible needed sources. you CAN get smart as to where you put the contents -
as i described, by tiling regions, marking tiles with a last updated timestamp
and the newer ones always move to video ram and older ones migrate back to
system ram (or slower memory - agp then system ram if you have 3 levels of
video ram usage and agp rendering ability in the driver), but thats as good as
it gets. x cannto do much more than that.a composite manager that does a lot of
smart stuff COULD go "oh - that window is obscured by other windows on top, AND
i dont have a thumbnail of it in the pager AND i dont support "expose" so i can
stop its direction". the problem here is - that to start redirection again will
mean artifacts either as a lag as the comp mgr WAITs for the app to redraw
itself or as there being a lage on redraw then one or more updates as it
becomes visible. the advantages of compositing is that once drawn - this doesnt
happen. when  the composited window raises on top - it does so instantly - at
the speed of a blit as no contents need redrawing. blitters on video cards are
insanely fast these days - to the point where a blit may aswell be almost a
no-op. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)