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

[Clemens Eisserer]

Sorry I forgot you're right and that they way you're doing things is fine.
GTK+ is a wonderful toolkit and prooves how well opensource works,
xorg has no weaks, mb sized pixmaps are allocated very quickly and
proprietary drivers are evil. To work on anything is useless since
next generation hw will eat the sh*t we feed current hardware today.
How could I have forgotten :-/

2006/7/13, The Rasterman Carsten Haitzler <raster at rasterman.com>:
> 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 (東京 日本)
>