CVS Update: xc (branch: trunk)
Luc Verhaegen
libv at skynet.be
Wed Oct 26 00:31:17 PDT 2005
On Wed, Oct 26, 2005 at 12:25:50AM +0200, Thomas Hellström wrote:
>
> 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
> enabled.
>
> 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.
>
> /Thomas
>
I wasn't saying that what you did was wrong, i was just curious as to
why this happened.
Urgh, yes, this code still checks the RegionsEqual twice... I spent most
of the summer wondering what those people at VIA were thinking when they
wrote any of the Xv code. I seem to be suppressing the worst of the bad
memories.
In that light your choice doesn't seem that negative, as there's already
one RegionsEqual call less.
X.org already has REGION_EQUAL btw.
This does lead to something else though, namely, why is all this
colorkey handling down in the DDX? XV_AUTOPAINT and XV_COLORKEY are
afaik standard. All handling could be in the DIX, with the XV_COLORKEY
only passed on for the overlay to adjust to. Does the colorkey painting
need to happen that closely intertwined with other overlay engine stuff?
Surely with an efficient PutImage, that needn't be the case. It would
avoid going into ReputImage at all in some cases.
Painting the colorkey right after PutImage might even reduce the effect
of first-run-garbage. Like on the CLE266A, where the HQV needs to be
flipped twice for something useful to be presented to the overlay
engine. It might provide for a smoother transition at overlay start. And
it does make the DDX code simpler and shorter.
It would break my alpha plane. Any other drivers doing funky stuff with
the colorkey rects? Maybe some devices need special handling of a
missing colorkey?
Luc Verhaegen.
More information about the xorg
mailing list