Xrender cursor performance / double buffering?

[Jim Gettys]

Jordan,

One can compute the cursor image once to match the depth of the root
window once and store it in devprivates.  Then the server can composite
the image using the fast path image compositing hardware, no matter what
the depth is (it won't matter if computing the cursor to match the
screen takes a bit of time; it's the compositing while the cursor moves
that really hurts).
                              - Jim


On Tue, 2007-04-17 at 10:56 -0600, Jordan Crouse wrote:
> On 17/04/07 18:22 +0200, Bert Freudenberg wrote:
> > On Apr 17, 2007, at 17:40 , Jordan Crouse wrote:
> > 
> > > On 17/04/07 17:37 +0200, Bert Freudenberg wrote:
> > >
> > >> Besides, the OLPC default cursors all use ARGB, not 2 bit.
> > >
> > > Again, I have to ask.  Why are we purposely hurting ourselves?
> > 
> > Well, ask Eben, not me ;)
> > 
> > Seriously, OLPC decided it's a good idea to have antialiased graphics  
> > everywhere. So why would you exclude the cursor from that?
> 
> Because the hardware doesn't support it, for one.  I would sure love to
> read the minutes from the meeting where a risk analysis was done between
> 2 bit cursors and ARGB, and everybody agreed ARGB was a better choice.
> Just because the technology behind 2 bit cursors is ancient, that doesn't
> make them unusable for this project.  we have many brilliant graphic artists
> working on this - is it really difficult to come up with a set of
> good looking 2 bit cursors that doesn't harm the look and feel of Sugar?
> 
> Jim has asked several times if the alpha blending unit can be used to help.
> I'm not sure if the X software cursor engine has the capacity to use the
> EXA composting, and even if it did, it would hurt performance even more on
> GX, because the hardware can't composite ARGB32 on native screen mode.  The
> LX can, but three months from now, I'll still argue that there is no really
> compelling reason to have a ARGB cursor.
> 
> Jordan
> 
-- 
Jim Gettys
One Laptop Per Child