EXA

[sshachar at t2.technion.ac.il]

Hi all,

Recently I've added EXA support to an existing driver for an imaginary card I
have in QEMU (It's a long story..). I'm running the latest Debian which makes
heavy use of antialiased fonts and transparency, however even when I exposed
the full set of EXA functionality (e.g. always returning TRUE for check
composite) antialiased font rendering doesn't seem to be passed down to HW.
Actually, almost the only place where acceleration is used is the software
cursor! :(

Note: If I change to non-smoothed fonts I start seeing major amounts of 1bpp
alpha compose requests which is what I expect.

Some digging in the server code revealed that exaCompose is called for
antialiased fonts (for example), but still the driver isn't handed down these
requests which are (using print fallback in exa_render.c), for example:

op OVER
src (m) ARGB8888 (1x1 R)
mask (m) A8 (14x11)
dst (m) XRGB0888 (40x17)

I'm now trying to add some more prints, but according to the code the only thing
that could make EXA fall back to a non accelerated compose would be a bad repeat
(not RepeatNormal or 0) or an alphaMap-ed src/mask/dst. I suspect the latter
(adding prints and compiling the server on my QEMU takes forever and I cant
wait plus i don't know if it will reveal anything useful so hence this post).

Am I doing something horribly wrong here or overlooking a basic issue? I
expected EXA to accelerate most antialiased font rendering and most if not all
composite primitives like in xclock's hands or the desktop drag and mark
rectangle, and certainly not only the SW cursor which in most cases is never
used to begin with.

Thanks, s