small repeating patterns == pain

[Jaymz Julian]

Today's fun 3am thought: Due to the call overhead, performance increases by about
2:1 when the xcompmgr background is changed from being 1x1 to 128x128, due to
the call overhead of repeatedly calling fbBlt(), and later fbCompositeGeneral(),
on this single pixel over and over and over (and, indeed, when i implented a
solid fill, it all went to shit when i started kde, and it's background was in
some fun colourspace which made things revert back to calling 
fbCompositeSrcSrc_nxn millions of times).  

Now, this can obviously be fixed by implenting a whole bunch of solid colour 
special cases, but as soon as we hit a general composite with this at any time
(I am unconvinced that all special cases will be covered ;)), things go downhill
*very* quickly, of course.

In that vein, shouldn't the composite manager be not using a 1x1 picture? :).
and, in a suggestion that is sure to get me flamed, would a minimum repeat
size of, say, 32x32 or something similarly small be the worst idea ever?  I 
realise that it does make life a tiny bit more difficult for developers, tho
I suspect that it could be implemented in libxrender in such a way that it is not
an issue outside of it (I havn't yet understood quite enough of it to be sure
of this, tho, nor to, i suspect, fully understand the difficulty thereof 
(although it seemed simple enough on my cursory glance).

	-- jj

-- 
--
Jaymz Julian aka A Life in Hell / Warriors of the Wasteland / Unreal
Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people. 
 Very few people have `I want to be killed and eaten' on their cards, 
 so Hannibal is out of a job." - http://cards.sf.net