Re: [MiNT] XaAES palette colour handling

[Standa Opichal <opichals@seznam.cz>]

Hi!

On Thu, 12 Feb 2004, Odd Skancke wrote:

> > Why did you touch this piece of code? Because it doesn't work with your
> > oVDI I suppose. Hmm, I also needed to change many things in the ARAnyM
> > fVDI driver for that. Please read that code again and try to understand
>
>  Ok, I have reread that source, and now I'm more confused than ever. I
> though that palettes set on one workstation should not affect any other
> workstations (except that it does in CLUT modes).

This is correct, of course.

> Lets assume from now on that we're talking about non-clut modes. Under
> such circumstances, changing the first 16 pens will not affect other
> workstations (or other apps),

It should not affect the other vwks at any time IMHO.

> but still it renders concepts such as desktop themes useless. Do you want that?

Here I completely don't understand you.

When I open a new vwk and set the palette for that, after that I use this
vwk to fix (convert) the CICON bitmaps to the screen color depth. Then I
close that created one. XaAES doesn't handle (use) the palette when in
CLUT mode. So this new virtual workstation is only used when in HC/TC
modes (see where the vdih is passed to and trace down to see). And for
this reason it doesn't hurt to set that all.

Concerning the TosWin2.rsc. Yes, this was yet another one that I needed to
fix. Because it contained the extension (RSC color palette), but had it
empty.

The RGB = 0,0,0 is BLACK, right? So how do we know that it is really a
flag saying that the palette is not correct? Perhaps if all of them are
0,0,0 then I would accept it, but otherwise it is wrong and the RSC
palette extension needs to be stripeed off or filled with a correct values
(like I did for the default widget.rsc - see the cvs log for that - I went
to Interface and fixed the values to contain the needed ones).

> And now the thing I'm confused about;
>
>  You open a workstation, you modify the palette on this workstation, and
> you close it again? I must have missed something here, because if not, I
> dont have a clue how VDI should handle virtual (or local to the owners
> apps) resources. oVDI, when in non-clut modes, keeps a separate palette
> for each virtual workstation that is opened. In effect, changing the
> palette like in LoadResource, then close the virtual, is a vaste of time.
> I just cannot believe that changing, lets say, color 23 of one virtual
> should change this colour of all other virtuals as well?
>
>  In CLUT modes, ovdi does not keep a separate palette, since such palettes
> are global, i.e, a change in one palette affects the actual color
> displayed, and in this case the opnvwk(), vs_color(), clsvwk() scheme will
> work. However, I still think this is wrong.

You confusion is not really needed. Get back to your original design.
Color palette is always local to the vwk. This is correct. In CLUT mode
the color palette loading is really just a waste of time, because it is
not needed.

>  As far as I know, there is no support from the VDI's side to set a
> palette on an 'application basis', that is, setting palette that will
> affect all workstations opened by a process.

Correct.

>  What I can see from this, is that the virtual used to attribute the
> resourcefile, is the virtual one must use to render the resource file to
> screen, if using the palette in that resource file. I got around this
> problem in my object library using color distance calculation when in 256
> color LUT modes. I have plans to do something like that in XaAES as well,
> which will make palette modifications not needed.

Well it is still better to use that palette modification for HC/TC
(non-CLUT) modes.

> > that. I must have changed the driver color handling completely for this I
> > must say....
>
>  I dont understand.. please explain.

I had only a single palette and the fVDI driver interface was getting the
pen number, but I didn't have access to the fVDI's palette there. So I
changed the fVDI driver to accept directly the HW dependent color value
(got from the palette lookup). This seems not to be that important in oVDI
concern as you explained that you keep the palette local. And perhaps the
driver doesn't need to know about it (it is already looked up, if
applicable, before getting into the actual drawing routine).

best regards

STan