No subject

depending what the actual details of the operation are.

"Masks can be only done with a 8bpp or 4bpp depth" happens if the given
alpha mask is, well, not 4 or 8 bits per pixel depth. I can imagine some
optimization possibilities here if all the alpha pixel values could be
transformed without loss of detail to a temporary 4bpp or 8bpp alpha
mask instead, e.g if the mask is actually 1bpp, 2bpp, or if it's 16bpp
or 24bpp with the least significant bits somehow not mattering (not sure
what the depth conversion logic here is offhand for them to not matter
if converting depth down).
Perhaps you could try printing out the actual value of pMsk->format
there and see what the depth and other details are when it fallbacks
most often.
It seems you can get details of the format with the following macros:

PICT_FORMAT_BPP(pMsk->format)
PICT_FORMAT_TYPE(pMsk->format)
PICT_FORMAT_A(pMsk->format)
PICT_FORMAT_R(pMsk->format)
PICT_FORMAT_G(pMsk->format)
PICT_FORMAT_B(pMsk->format)

For comparison, PICT_a8 would be 8bpp, type PICT_TYPE_A, and values of
8, 0, 0, 0 for A, R, G, B - those tell how many bits per pixel for
alpha, red, green and blue channels are used.


"Transform operation is non-trivial" should happen basically if the
transform isn't just a full degree rotation, as the Geode hardware can
do only 90, 180, 270 degree rotations basically; which is important to
have for rotated screens.
Depending on the actual transformation, perhaps something tricky can be
figured out to do it, as it isn't necessarily some kind of rotation, but
could be a different kind of transformation in there - so according to
the exact details of nature of it, perhaps something could be done to
hardware accelerate it.

"pSrc should be 1x1 pixel if pMsk is not zero" happens when it tells it
happens. I'm not sure if we could do something with more complex sources
with masks than just a pixel. Needs some thinking there.


All these fallbacks would also be less costly, if we didn't end up
migrating the pixmaps out temporarily from video memory to system
memory. I believe that theoretically pixman based software fallbacks
could be done inside video memory, but I didn't get EXA classic mode
convinced of that yet to try it out. As in, video memory is really just
CPU memory too, just framebuffer memory set aside into which hardware
accelerated operations can put their result in; so if we were doing
software operations in there as well if there's enough room, without
migrating out of there, we could avoid the costly part of copying memory
around too much and fix it for all cases to not be SO big of a
performance hit, while it'd be still nice to do in hardware what is
possible.

If you have a custom drawing code you need to have fast, then an
alternative could be to change the drawing operation at the application
level as well. But that's not really feasible for a generic desktop
system or so.


Best Regards,
Mart Raudsepp