Didier Verna <verna(a)inf.enst.fr> writes:
jareth(a)camelot.co.jp (P. E. Jareth Hein) writes:
> After a forced education into the wonders of specifiers and their care
> and feeding in C,
I know what you mean :-)
> Now the background for display is the same as the background of the default
It works, thanks. Now I have a quizz for you (please select what you
think is the correct answer):
Q: What if I have a background pixmap for the default face ?
A: [ ] a background what ?!
[ ] huh, dunno.
[ ] I don't give a f*cking damn.
[X] Then, remove it.
[ ] No problem, here's a new patch :-)
Seriously, that's a rather large and squirmy can of worms. The
current instancing mechanism has no idea of where the image will be
placed, so while I can place the pixmap behind the image, I have no
way of making sure that the tiling of the background image will match
where the image will finally get placed. I'll look into fixing it for
21.1, but I think that creating proper alpha support for overlaying
glyphs, etc onto other things is about the only way we can get that.
That will allow a lot of cool things, but will take quite a bit of
work on modifying redisplay and also won't function on colormapped
consoles. Passing in the target x,y coords will also fix the problem,
but that means each instance of an image is potentally unique and
defeats the cache mechanism. I suppose we could extend the glyph
structure to contain a bit on whether or not the instance is unique
(if is uses the passed in position info, perhaps)... I'll think about
Jareth Hein | jareth(a)camelot.co.jp | ハイン ジェラス
Toolsmith & Program lead | http://www.camelot.co.jp
Camelot Software, Ltd. | |（株）キャメロット
"It's a sad sign of the times when 'political machine' is redefined to
include 'main-line battle tank'" - Ambassador Grossblunder