CVS Update: xc (branch: trunk)

[Thomas Hellström]

> On Wed, Oct 26, 2005 at 12:25:50AM +0200, Thomas Hellström wrote:

>
> In that light your choice doesn't seem that negative, as there's already
> one RegionsEqual call less.
>

Yes, but on the other hand, since the repaint helper takes the cliprects
as arguments there should be no need to repaint the colorkey when
cliprects hav not changed. Actually, what seems to be happening on a
window change is

1) Putimage is called with new window location / dimensions and old
cliprects.
2) Reputimage is called with new window location and old cliprects.
3) Reputimage is called with new cliprects.

It is correct, but seems a bit inefficient.


> 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?
>

Xv can be implemented without overlays. Either using 3D textures (which is
possible also without DRI), or in the case of the Unichrome PRO A, using
one HQV for downscaling and color transformation, the other for upscaling
directly to the frame buffer. There must be a way for the DDX to turn off
colorkey handling.

>
> Luc Verhaegen.

/Thomas



> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>