[wmii] Re: (pseudo-)transparency bug in rxvt-unicode >= 5.x

Hi Marc,

On Fri, May 19, 2006 at 08:08:16PM +0200, Marc Lehmann wrote:
> On Fri, May 19, 2006 at 12:20:19PM +0200, "Anselm R. Garbe" <garbeam_AT_wmii.de> wrote:
> > Just for documentation, I give no shit about it anymore,
> > because it seems that my mail has been defered by the developer
> > of rxvt-unicode.
>
> Your mail has been sent out by your mail server at "Fri, 19 May 2006
> 13:03:34 +0200". It was sent to subscribers around "Fri, 19 May 2006
> 13:09:36 +0200" (at least thats when I got my copy, the web archive itself
> as updated 6 minutes earlier).
>
> Neither was it deferred, nor moderated nor anything else short of a timely
> delivery happened...

Well, sorry for making a wrong assumption that you deferred my
mail. But you didn't reacted to my statements in your IRC
channel, although you talked with other peoples hours later.
This made me feel that you ignore well-intended advices and bug
reports. And the mail delivery took pretty long on your side
which made me feel, it has been deferred. (I still suspect if I
hadn't made this public, it would have been deferred... but oh
well). If you had replied a single word on IRC, I won't have
done so. I waited a day, before acting the way I did. And I
regret nothing. I hope you learned at least, that it is not a
good idea, to ignore bug reports, if people invest a bunch of
time to do bug reporting.

Anyway, I hope we can continue discussion politely.

> The above claim (lie?) is symptomatic for your behaviour. I would have
> ignored it if you wouldn't have dragged it into public yourself :/

Aha, that proves my suspicion to some extend.

> > However I'm subscribed.
> If you weren't, the mail would have been defered for moderation indeed. It
> usually takes a day until it gets forwarded, but in your case, no such thing
> happened, nor took it more than a few minutes to forward your mail to
> subscribers.

I know, I maintain mailing lists as well.

> > I joined the IRC channel to report schmorp about a bug in rxvt-unicode,
> > yesterday. Because he didn't seemed (http://wmii.de/urxvt.bug) to be
> > interested in it, I send this report to this list. I digged into the
>
> Well, at least you did your homework in the meantime. In IRC, you insisted
> on xlib sending expose events to other applications and other very
> confusing (actually wrong :) notions about X11. Since you didn't answer my
> questions about the actual symptoms, I indeed wasn't much interested in
> your "report", as there simply wasn't any.

I still doubt that you have read what I wrote you in the IRC, I
even repeated pasting the symtoms I told you - everyone can
recheck this in http://wmii.de/urxvt.bug.
Grep for 'event' in the Xlib source, follow some interface
functions in their flow, e.g. have a look into KeyBind.c and see
what Xlib does with events to interface functions and how it
communicates with the X server.... Why do you think all X
events are defined in Xlib.h? Because the Xlib has nothing todo
with events...? Also have a look how Display is organized...

> > rxvt-unicode code on my own, and found a semi-solution, which fixes the
> > bug for me, but not in general, because the overall behavior of
> > transparency-related refreshes in rxvt-unicode is quite broken.
>
> Thats a bold, and untrue, statement that you cannot back-up (mostly
> because you prove that you don't know the transparency code of urxvt in
> your own mail).

I want to tell you how I behave in the wmii project if someone
reports me a bug. I listen, I think critically and I often can
confirm that I've been the moron (I've no problem being a moron,
because I know that nobody is perfect). If I did a bug, I can
agree with it, that I did a bug. And my sorry if I did a bug in
my code is to fix it and to take care not repeating it. To
analyse my fault, that it doesn't occures next time.

Your statement looks like, that you believe being a programming
god that you haven't done anything wrong. Hello? Your client
breaks ICCCM when run in -tr whenever a ConfigureNotify reports
a geometry change. More than that, you clear windows you don't
own. That is TOTALLY broken, and it makes your app a broken app.
Do you think it is not broken if a window manager would begin to
clear the vt window radomly on resizals? And then it is not the
window manager's fault? Such a window manager isn't broken? oh
dear...

> > If rxvt-unicode is run with -tr (Opt_transparent) argument, then it
> > performs XClearWindow calls on its parent windows, which rxvt-unicode
> > does not own(!) at all.
>
> In some cases, yes, this is what happens and what _has_ to happen for it
> to work. It doesn't happen with your wm... Tough! It works with much more
> common window managers out there, though. Your hack would probably make it
> work with your wm and would break others.

I told you why this works with those common window managers.
Because they set their frame drawing as pixmap for the window
background. But anyway clearing such windows as client app is
broken. Personally I'd vote to close the connection to such apps
if they do so (internally in the X server).

> In any case, if that mode of transparency doesn't work with your wm, you
> are free to use another that will work. The world isn't perfect, and that
> particular way of implementing pseudo-transparency cnanot work everywhere.

Well, if it does not work, then fix it. The problem is not in my
software, it is in yours. Or just drop the complete -tr
insanity. Who needs -tr?

> Reading the documentation or even the FAQ would have helped a
> long way, of course...

I didn't found any info about this issue in the FAQ, and I don't
believe that pseudo-transparency cannot be made to work
everywhere, because other terminals do it correctly without
clearing windows they don't own. Claiming

"Please note that transparency of any kind if completely
unsupported by the author. Don't bug him with installation
questions!"

does not fit into my focus, because it was no installation
question. And if it is unsupported, why don't you remove this
transparency stuff?

> > Besides this, a side-effect (which is quite a hack indeed) is used in
>
> This kind of pseudo-transaprency is indeed a hack, and indeed is not in
> compliance to the ICCCM. Neither is your proposed solution, of course,
> which, as I mantioned, just breaks other WMs.

My proposed solution is fully ICCCM-compliant, because it
doesn't break any convention. It won't clear foreign windows
randomly. Even if XROOTPMAP_ID isn't defined by ICCCM, this
doesn't breaks ICCCM, because it is a valid property which can
be fetched from a well-defined window, namely the root window.

> Thats the reason why rxvt-unicode implements correct transparency, too,
> and pixmap-pseudo-transparency, too.
>
> Neither of those has the problems you claim they have.

Does something has been unclear when telling you hundred times,
if run with -tr? I don't care wtf you call this transparency. I
only care that it was buggy and I can't understand why you don't
agree that this is a bug.

> The really bad thing is that I told you about that in IRC, but you didn't
> listen :(

14:56 < schmorp> this is a known problem with the way io3n works
14:56 < schmorp> and its not avoidable
14:56 < schmorp> ion3 works correctly
14:56 < schmorp> but pseudo-transoparency cnanot work with the
way ion3 does
14:57 < schmorp> it can be made to work
14:57 < schmorp> but then it will stop working with other window
managers
14:57 < schmorp> its not possible that -tr works everywhere
without copying the pixmap or using real transparency, which
urxvt supports

I think you mean this excerpt that you told about it. Well
actually at this time I didn't saw any correlation to the
problem, and you never said, "well it could be that the frame
gets not drawn, because I implemented a hack which clears the
frame window, because I want to prevent flicker in KDE that way,
and this allows me to not copy a pixmap instead to my client
window only"...

You constantly insisted that the window manager must be broken,
although you obviously knew better. And not me bothered you, you
bothered me with all your offendings that I'm the clueless idiot.

I also tell you why this annoys me: Because there are thousands
of X client developers, who think they know X, and I have to
cope each day with broken apps to workaround any frking bugs to
handle those apps at least in a semi-acceptable way in wmii. If
all X client developers would agree to the ICCCM this would be a
starting point and avoid many workaround and hack in window
managers.

But in wmii, I already gave up the hope, that X client
developers will ever learn and read at least the ICCCM document.
All those apps which are broken are claimed to be broken by me.
And if I find a bug in such an app, I recheck if it is really
the app, and if I'm convinced it is, I report it. To give its
developer at least a chance to improve the quality of his
software and to fix it. That I don't need to claim it as broken.

And your terminal app is quite favorized in the wmii/ion3/larswm
community. And I even believe WE are YOUR users and community.
Those KDE/Gnome ***** don't use your app at all, so why do you
insist to prefer them with their bloaty desktop at all?

There is no decent terminal yet, and it is time for quite a long
to start a reimplementation from scratch to form a decent
terminal. At least you got it right to use UTF8.

> > To fix the overall transparency behavior, I make following proposals as
> > starting point:
>
> That is indeed a starting point. Fortunately, rxvt-unicode does not rely
> on the hackish and slightly broken algorithm you propose, but uses a more
> correct one (for example, it doesn't flash the screen as aterm does, nor
> does it fail to work with modern desktop-background-setting programs).

Sure is my algorithm hackish, because of the window creation
trick. But it is at least ICCCM-compliant. Honestly, if you really
want a sane transparency implementation, you should never need
to clear any window you don't own. And you won't get any flicker
if you do it correctly. Also, your implementation shows, (also
you differentiate between arbitrary transparencies), that
something must be seriously broken. Because if it would be not
hackish, but clean, you would use a pixmap in _any_ case,
regardless of the source of the pixmap (may it be a screenshot
to get 'real' transparency, may it be the root window pixmap -
regardless how do you fetch it, or may it be a pixmap supplied
by the user) - in any case the algorithm would be the same, and
my proposal works this way. It only uses different sources, but
those sources might not screw up the code with options and what
not.

> > - If you need (pseudo-)transparency, check if XROOTPMAP_ID is set as
>
> grep'ing through the rxvt-unicode sourcecode for XROOTPMAP_ID might be
> enlightening. Instead of "proposing" what rxvt-unicode already does, how
> about proposing improvements instead?

I haven't claimed you don't fetch it. I wanted to present you
an algorithm which is based on three steps:

- a) fetching the background pixmap into an offscreen pixmap
- b) mapping this to the vt pixmap where it has been exposed,
      doing the glyph rendering
- c) mapping the result to the vt window (this won't flicker,
     because you rendered off-screen)

As you see, a) and b) and c) are totally independent from each
other, the only interference is a pixmap. Your code doesn't
looks like it does it that way, at least it is quite screwed up
with ifdefs, I cannot understand the overall flow. And I cannot
understand code with is more than 10kSLOC anyway. Respect if you
can (but it doesn't seems that way). Even Ken cannot understand
65kSLOC.

> > Thus you don't need to clear any windows you don't own, you only need to
> > take care of your own vt window, and of the root window if you need to
> > fetch the XROOTPMAP_ID.
>
> It's just a matter of configuration and taste. For example, raeding the FAQ
> for rxvt-unicode explains all this. But, as I had to find out, reading
> documentation and dealing with facts are not your strong points.

Fact is that you clear foreign windows and that I even pointed
you to your code portions where you suppress any notification. I
could even point you to other points (just grep for strcmp and
follow the data flow, but I thought bugtraq might be a better
place maybe...)
Fact is, that I told you so and that I provided you the
symptoms. I was right that I reported you that I don't receive
Exposures, and I tried to understand why. You regretted to
recheck on your own, you even wanted to make me believe that
ion3 works correct, you presented me a shot and asked what's
wrong with it. I always told you, you have to click the tab. I
told you to check with windowlab. That are the facts.

> Either way, what you describe is just as broken (and not specified by the
> ICCCM either). There is a correct way: using a composite manager, which
> is well-supported by urxvt, probably better than by any other terminal
> emulator out there.

My above algorithm is exactly a composite managing algorithm,
because it composes your rendering with at least coupling as
possible (and I presented in my first mail even, at which time
one needs to tinting/shading if necessary to gain good
performance).

> There are currently four ways to get transparency with urxvt-unicode:
>
> 1. pseudo transparency using pixmap inheriting.
> * it's a hack, and will ever be a hack.
> (it is also what your patch breaks with many wm's)

It can be made to work correctly in any WM. Stop spreading FUD
please.

> 2. pseudo transparency by re-using the background pixmap
> * same configuration, works whenever a freedesktop-"compliant"
> background setting program is used.
> 3. pseudo transparency, using a prespecified pixmap
> * implemented by the "automove-background" extension
> 4. real transparency
> * must be specified by giving the background (or other colours)
> an alpha component. very clean solution, and correct, too.

No complaints, but all 4 ways can be used with the same
composition. I dunno if you do so (it doesn't looks that way as
I told). But maybe it is that way. But in any case, please stop
clearing foreign windows. And if you don't know a solution, then
remove the broken code at least. Thanks. If it works in KDE it
doesn't means that it is not broken.

> In any case, I don't know why you hate rxvt-unicode so much that you have
> to spread lies about it publicly. Obviously, you didn't try to read either
> the source nor the documentation before making your claims (which is
> exactly the same behaviour as in IRC, where you made me grep through xlib
> sources to find out that you were telling the untruth... "just believe
> me".. yeah.. thanks for wasting my time).

Where have I spread lies? I just hate it when people are
unwilling to listen, when they did something wrong. Your code is
broken, that is the fact. That is no lie.

> I am not amused, however. This is not a harmless prank by somebody who
> doesn't know better: You wasted quite a bit of my time by making lots of
> claims that are untrue or turned out to be untrue (this is refered to as
> "trolling"). All that was easily verifiable, but it still took time to do
> so. You are sabotaging free software development that way, as that time
> could have been used in a much more productive way, such as fixing actual
> bugs by other users.

If I were you, I had listen in IRC. I had rechecked the issue if
I weren't able to understand the problem as I described the
symptoms (even in my first sentence, "I don't receive
ExposureNotify"'s). You have not listen. And I will repeat such
actions whenever an developer does _not_ listen and thinks the
user is wrong.

> Your behaviour is _not_ acceptable :(

Your code quality is _not_ acceptable.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361