xorg Digest, Vol 25, Issue 89
jarno.manninen at tut.fi
Fri Aug 24 02:50:24 PDT 2007
Quoting Michel Dänzer <michel at tungstengraphics.com>:
> I suppose it can't combine the two modes to achieve 1234 <-> 2143?
Nope. Just only one port for conversion with one conversion type.
> Hmm, I guess the only thing preventing that is that EXA calculates
> pExaPixmap->fb_size assuming the bpp is the same as in system RAM...
That one is easy to fix, but real solution might require some
additional field in the ExaPixmap struct to track the sys/fb
depths/formats. Also any migration between sys and fb should take care
of the correct transformation.
However I'm not sure if switching the format in picture struct would
break something else. So hooking of the any Picture access might be
> Hmm, I think it might be possible to get at least some of the same
> benefits by just tracking damage for FB and SYS separately and only
> transferring regions between them that are actually needed for the
> operation at hand... interesting food for thought.
Obvious benefit over using only one damage area is that for off-screen
pixmaps the drawing operations could be accumulated until the blit to
visible area. Uploading after every operation (like I'm doing now)
might cause unnecessary uploads.
At least it would be easy to calculate the area for migration.
migrate(fb.damage UNION sys.damage)
fb.damage = fb.damage SUBTRACT (fb.damage UNION sys.damage)
sys.damage = sys.damage SUBTRACT (fb.damage UNION sys.damage)
Might be worth a try.
More information about the xorg