Re: pseudo transparency

[Owen Taylor <otaylor redhat com>]

Sasha Vasko <sasha aftercode net> writes:

> On Tuesday 15 January 2002 13:34, Owen Taylor wrote:
> > Sasha Vasko <sasha aftercode net> writes:
> > > >>That makes ParentRelative a very interesting alternative.
> > > >
> > > > I don't think RENDER (or plane masks) are actually useful with the
> > > > parent-relative thing since you have to _first_ clear, _then_ tint,
> > > > which is not going to look OK for ConfigureNotify or when scrolling.
> > >
> > > It looks wonderfull. I've been using it for 2 years and so did many
> > > others, and there was only positive feedback.
> >
> > As far as I can see:
> >
> > If you call XClearWindow(), then XFillRectangle() with a plane mask,
> > then there _will_ be a period of time when the window is drawn
> > untinted, and the user will see a flash if it occurs at the wrong
> > time. This is completely unavoidable with the standard X protocol.
> 
> You forgetting that with Eterm approach you need to regenerate your 
> background just as well (on ConfigureNotify), so you get flashing in any 
> case, it just may look differently. In addition when Eterm is moved it 
> generates notoceable spikes in CPU activity, while aterm's XFillRectangle 
> does not. In fact on slower CPUs it makes Eterm's refreshing much slower then 
> aterm's one. And over the wire XFillRectangle method appears to work much 
> better too (maybe because Eterm is not using XRender fully yet).

With your method, you will inevitably flash temporarily to the unshaded
background. If you have an actual handle to the root pixmap ID, you
can use a temporary backing pixmap (create, handle the new position, destroy)
and get no flashing at all.

> > > In fact ConfigureNotify handling in particular works much better then
> > > Eterm approach. Plus it is using much less memory.
> >
> > You can do the same XFillRectangle() trick using _XROOTPMAP_ID
> > .. there may be a tiny bit more lag than with the
> > parent-relative-background hack, since you need a round trip call to
> > XTranslateCoordinates, but it isn't going to use more CPU or more
> > memory.
> 
> Here is the real world test. XFree86 4.1, Eterm 0.8.10, aterm 0.4.2, 16bpp 
> 1600x1200, Matrox G450
> Eterm command line : Eterm -O --tint 0x0000FF
> aterm command line : aterm -tr -tint blue

I'm not commenting one way or the other on _how_ or _how well_, Eterm is 
implemented; my guess is that it doesn't use the planemask trick and pulls
the data from the server, munges it, and then pushes it back into a second copy
which it thens keeps around. 

My point is that you can use the planemask trick with _XROOTPMAP_ID.

Regards,
                                        Owen