CVS Update: xc (branch: trunk)
unichrome at shipmail.org
Tue Oct 25 15:25:50 PDT 2005
> On Tue, Oct 25, 2005 at 10:18:30AM -0700, Thomas Hellstrom wrote:
>> CVSROOT: /cvs/xorg
>> Module name: xc
>> Changes by: unichrome at gabe.freedesktop.org 05/10/25 10:18:30
>> Log message:
>> * programs/Xserver/hw/xfree86/drivers/via/via_video.c:
>> Colorkey autopainting bugfix
>> Modified files:
>> Revision Changes Path
>> 1.1474 +6 -0 xc/ChangeLog
>> 1.14 +3 -5
> I'm curious. What bug does this fix? What are you seeing?
> Surely the colorkey doesn't need to be written to the FB each time, say,
> only a new frame is sent (which is undoubtedly the most common case).
> When focused on cpu usage, that's quite a few cycles you can spare right
With the current code, The colorkey is only painted when the overlay is
updated, not every frame. Previously it was painted only when the
cliprects changed, so it is not a big CPU-eater. What I actually am seeing
is that xine sometimes misses the title screen when autopainting is
Even more confusing is the fact that XvPutimage is called with the old set
of cliprects when a change in the number of cliprects has triggered an
expose event in the player.
However, while the above made things better I just saw this happening
again, so this is probably a bug in xine-ui, clearing the output window
after the colorkey has been autopainted.
I'll revert the commit.
> Why remove it in PutImage and keep it in ReputImage?
> If initialisation is what you're worried about, StopVideo and
> SetupAdaptors seem to take care of that.
> Luc Verhaegen.
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the xorg