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 <[email protected]> > 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 >
_______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
