On Tue, 25 Nov 2003 23:37:36 +0100 Adria'n Casaju's
(B[EMAIL PROTECTED] babbled:
(B
(B
(B
(B How about thumnailing windows when they slide out of your viewport? That
(B way you could have all the windows thumnailed and access to them at
(B once. And another plus is that time spent thumnailing is split and you
(B don't spend all the time getting the images when going to show them.
(B
(B
(B
(B it also means keeping LOTS of copies of window contents around you may never
(B actually use, and what about when a window lowers itself? or another raises?
(B keep grabbing windosw contents just before every operation...
(B
(B have i also pointed out that READING the framebuffer is about 10 times slower
(B than writing to it? ie grabbing window contents is a very expensive operation
(B to be avoided as much as possible?
(B
(B
(B
(B The idea is to keep just the latest copy of actual windows. If is comes
(B
(Band THAT part involves keeping lots of memory around for the pixmaps... let me
(Bjust give an example.
(B
(Byou have 4 desktops "worth" of windows. lets say on average they overlap some,
(Bbut some space is between windows - so lets be conservative and say 80% screen
(Bcoverage. you run 1600x1200 @ 32bpp. to do proper scaled down versions you
(Bactually have to keep full res shadow copies of every window. (it is to an
(Bextent possible to justupdate thumbnails - but it depends what size thumbnails
(Bare etc.) thats... 1600x1200 * 4 * (32 / 8) * 0.8 bytes of ram... 23.4Mb... kept
(Baround ALL the time... just in case you go into expose mode... let me think
(Babout this... errr... NO. (ok now we can argu where this memeory lives. on video
(Bcard? in system ram? if scaling we'll need it to sit in system ram anyway...
(Btheres caveats. i wont go into them all).
(B
(B to be a useful feature there will be very few ones not used. But aside
(B of that, just grabbing data from the bramebuffer for a window whenever
(B you iconify it, lower it or it slides around is not too much times, but
(B still not very few. You could keep as an option. I now it is really easy
(B to say thing and do nothing as I am doing but I'd like to contribute in
(B some way like giving ideas.
(B
(Balso rememebr it adds overhead. EVERY operation (raise, lower, move, resize)
(Bwill then invole e having to grab the screen again... i repeat. READING the
(Bframebuffer is an order of magnitude slower than writing on almost ALL video
(Bcards. in the past i have seen something like 1/10th the speed of writes. that
(Bmeans more overhead for everything you do by a large margin, more sluggish
(Bperformance, more memory used... yes its possible - but the "cost" is VERY VERY
(BVERY high and its still only partly done becuase you cant track window updates
(B(the contents change form the last tim the window was moved or resized - your'e
(Bwatching a video, or drawigng in gimp etc.) and if you dont move or resize the
(Bwindow then it wont update fully - now u need to continuously scan pixels ALL
(Bthe time (e16 does this taking a LOT of shorcuts to minimize impact). it's very
(Bexpensive... theres a much better way around the corner doing it via xdamage and
(Bxfixes etc. when they become real commonplace extensions. then it'd be possible
(Bto get expose, alpha blended windows, REAL updating icon thumbnails of windows
(Bin pagers and the iconbox... and much much much much more... done right :) but
(Bthis might be a little ways off.
(B
(Banyway. for now in e17 this isnt quite on the cards... for now. give us time to
(Bfix up the basics again :)
(B
(B --
(B -
(B http://EuropeSwPatentFree.internautas.org/
(B Per una Europa sense patents de programari.
(B Por una Europa sin patentes de software.
(B Because I want a software patent free Europe.
(B
(B
(B
(B--
(B--- Codito, ergo sum - "I code, therefore I am"
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$B7'<*(B - $Bhttp://sourceforge.net/donate/
(B___
(Benlightenment-devel mailing list
(B[EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
