Performance change from X in Fedora Core 4 to Fedora Core 5

[Carsten Haitzler (The Rasterman)]

On Thu, 13 Jul 2006 08:01:51 +0200 "Clemens Eisserer" <linuxhippy at gmail.com>
babbled:

> > it is give and take. you incur some extra expense for a temporary pixmap
> > allocation and de-allocation in return for not holding on to that video ram
> > permanently and thus eventually running out of video ram and needing to swap
> It seems as we don't get ahead anymore.
> 
> Keeping in mind that the extra pixmap most likely will be used only
> extensivly in short timeframes (user is activly using the gui,
> expose-events because another window is moved in front, ....) and that
> in this short timeframes the goal is to archive highest performance I
> think there must be better ways than allocation and deallocation every
> expose.
> 
> I don't see a problem with memory useage, almost all graphic-cards
> have more than 16mb which is more than enough.
> Furthermore implement almost all drivers I know about quite clever
> swaping algorytmns and who cares about a pixmap in RAM which isn't
> used frequently anyway...

16mb! hahaha - dream on. let me give you a quick example:

my laptop has a 64mb radeon 9000 (r250). lcd panel is 1600x1200. you start x
with DRI - ok. 32mb vanishes into DRI. 32mb left. just under 8mb vanishes into
the framebuffer. ok - 24mb. now i - like most people, have a desktop wallpaper
- another 8mb. 16mb left. that is enough for 2 fullscreen windows in a
composited environment before you run out of video ram. we4 arent even talking
about video ram for icons, buttons, theme elements, temporary rendering pixmaps
etc. etc. - you want to save video ram wherever you can. composited
environments eat up video ram like there is no tomorrow. a composit manager
doesnt know when you run out of video ram. it doesn't know if it should free up
pixmaps for iconified/minimized windows (it is keeping around so "expose osx
like things can work). now you just end up in pixmap video ram thrashing and
performance drops like a stone to the bottom of a very deep river.

we do need to consider conserving video ram. as resolutions go up (1920x1200
and up) and people do twinview/mergedfb etc. and now have even more screen
realestate... and they like to run lots and lots of apps - like they always
have done... dozens and dozens of xterms over many virtual desktops across
mutliple monitors... that adds up REALLY quickly. the allocation/de-allocation
is not much effort at all as you allocate then do a lot of drawing TO the
pixmap (composite/draw many layers of gfx) then copy to destination then
release.

> I think a lot vram can be saved if you take a bit care about how long
> holding the pixmap:
> 
> Solution 1: only hold it when the window is visible or in a state
> where a expose could happen.
> Solution 2: Solution 1 + some algorytmns which free the pixmap after
> it has not been used for xy seconds.
> Solution 3: Your idea ;-)
> 
> lg Clemens
> 


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