CVS Update: xc (branch: trunk)

[Luc Verhaegen]

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.