Re: [AD] Windowed drivers color conversion

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Cool if you could modify the update routine to accept that kind of
> structure and not a DDSURFACEDESC structure...

Ok, I'm going to do it.

> Huh?? It seems these are actually used inside update.s, to know how many
> lines to convert...

I was specifically talking about the *dest* rectangle: the code assumes that
both width and height are the same for the src and the dest rectangles, so
it doesn't read these fields for the latter (i.e no stretching).

> I don't think it'd be that hard to add 15bit support at this point.

The lack of the 'from' 15-bit support isn't really annoying: it simply
mimics the fullscreen driver, for which most graphic cards support only one
mode amongst 15-bit and 16-bit color. The windowed driver supports 16-bit on
every desktop, except of course on 15-bit one where it would be a shame to
use 16-bit to 15-bit conversion.
But I'm ok to add 15-bit to 24-bit and to 32-bit if you want.

> Truecolor to palette would require much more work, and I'm a bit lost in
> it currently, so maybe this is a job for Michael or Peter, who coded the X
> and BeOS drivers (that support also this kind of conversion).

Yes, and I wonder if asm could bring any significant improvement here.

> It depends. On QNX I think I can make it to point directly to the real
> display RAM. But on BeOS and X that is another buffer of the same depth as
> the real display.

So one backbuffer for QNX and two for BeOS and X ? Under Windows, it's one
and half !
More precisely, the code does allocate two backbuffers like in X and BeOS
but doesn't always use them: when the window is entirely visible, it
bypasses the second one (with the same depth as the real display) and write
directly into VRAM. But the mechanism has of course a real weakness so we
may have to switch to the more conservative two buffers method before 4.0 .

> humm, now I think the init routine I proposed doesn't really fit in this
> scheme at all... What do you suggest to make an unique API?

I'm suggesting to make a more low-level API than your initial proposition:
the BLITTER_FUNC type would match the modified type of the asm routines and
we would basically have a getter function like:

   BLITTER_FUNC *get_color_conversion_blitter(int from_depth, int to_depth).

It would be responsible for selecting the right function or return NULL if
no blitter is available.
So we keep the backbuffer business at the driver level, which is IMHO easier
and safer for the time being.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx