Re: Quick thought - cheaper transparency
- From: raster rasterman com
- To: M Rogers cs ucl ac uk
- cc: wm-spec-list gnome org
- Subject: Re: Quick thought - cheaper transparency
- Date: Tue, 21 Mar 2000 08:46:27 -0800 (PST)
On 21 Mar, Michael ROGERS scribbled:
->
-> >first - under things like xfree 3.9/4.0 it weont help much since
-> >pixmaps get cached - thus doing an XCopArea of a pixmap to another to
-> >re-tile it at a new origina is almost effectively a null-op or most
-> >cards since the bliter is pretty damn fast. infact if you
-> >XFillRectangle the root pixmap into the window with the right offests
-> >it is no more work at all (on synthetic configure ntoify do a repaint
-> >with an XFillRectanlge of the pixmap id set as a property on the root
-> >window used as a pixmap fill with the fill origin set appropriately)
->
-> On my system there's a noticeable delay between moving a transparent terminal
-> and seeing its background updated - I guess this is because it only checks
-> that its background is up to date a few times a second? (As you say, you
-> wouldn't expect the actual drawing to take long at all.) I think that if a
-> ParentRelative background was used, there would not be a noticable delay
-> because the background would be updated automatically by the server. Might
-> look nicer, especially for opaque window moves.
actually.. that is likely an event queue/ terminal/wm combo problem.
if you opaque move in E E wont send the synthetic configurenotify
untilt he move is complete - so the term doesnt know its been moved
until you "drop" it. some other wm's do the same.
then the app still has to get this event, process it and figure out
what to do - ie the app will havew to, even if it has a parentrelative
g , do XClearWindow and do a redraw. Eterm for exmaple does an
XCopyarea to its bg pixmap with the correct offests, XClearWidnow then a
redraw. thats 1 extra copy there compared to the minimum - i suppose i
coudl hint to michael to change it :) but if the pixmap is cached in
offscreen video ram (as xfree4.0 now does) then its almost a null op as
blitting around the gfx cards video mem (not goign across the bus) is
so damn fast these days its almost a null op :)
parentrelative doesnt update the bg automatically whenevr the window is
moved or resized - you do have to manually clear thw window.. so it
doesnt help really - its just a convenience :)
so i think what you have is more a case of bad coding somewhere :)
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com
raster@enlightenment.org raster@linux.com
raster@zip.com.au
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]