The motivation of adding fallback_counter to exa

[fly fancy]

Thanks a lot! I would agree with your explanations. However, I have another
confusion.
In mixed pixmap mode, when the arguments 'w' and 'h' passed to
exaCreatePixmap_mixed is either zero,
this pixmap will become a driver pixmap through exaCreateDriverPixmap_mixed
right away. Usually,
in this situation, the exaModifyPixmapHeader_mixed should be called with
non-null pPixData. But,
exaModifyPixmapHeader_mixed will delete pixmap driver private when pPixData
is non-null and set
this pixmap pinned. Therefore, I think this(create pixmap driver private,
then destroy it without using it) is
meaningless. Do I understand it wrong? Thanks!

Best wishes

2010/10/12 Adam Jackson <ajax at nwnk.net>

> On Tue, 2010-10-12 at 11:34 +0800, fly fancy wrote:
> > Hello, all
> >             In newer XServer edition, the fallback_counter is
> > introduced to EXA. However, I almost can not understand the motivation
> > of the fallback_counter mechanism. Anyone understand it? I'll be very
> > appreciated for your explanation. Thanks !
>
> Near as I can tell (the commit message isn't great), it's like this:
>
> Sometimes, you're doing a software fallback, and to do that fallback you
> need to draw into a scratch pixmap and then scrape the bits out of it
> and put them into the real destination.  Any scratch pixmap so created
> should itself be rendered entirely in software in host memory, since
> otherwise you'll be reading bits back out of the framebuffer and that's
> _super_ slow.
>
> So once the fallback count is non-zero, force everything to the host
> memory path; and then allow it to be an integer so recursive fallbacks
> work (which is pathological, but I guess it could happen).
>
> - ajax
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20101014/033860dd/attachment.html>