ma, 2006-09-18 kello 11:39 +0200, Martin Wache kirjoitti:
> Heikki Lindholm schrieb:
> > The included patch makes dfb:mgatv use YV12 colourspace for video and
> > the hardware subpicture layer for OSD. The patch is a prime example of
> > bad goal-oriented programming, but does what I wanted: improves
> > performance to the level that my 450 MHz P2 can now function as a DVB
> > box like no underpowered P2 has done before! Unfortunately, the patch
> > probably breaks everything else, but I'm too lazy to clean it up.
> >
> Can you please point out to me what the advantage of using the
> subpicture layer is? To me it looks like the main speed change is that
> you don't scale the osd. Or does the change to YV12 colourspace bring
> some speed advantage?
Wow - this list has wonky ordering. See my previous mail about this.
> I would not mind adding support for an indexed bitmap, but currently I
> don't see the advantage. If we do that we should probably think again
> about the interface of GetOSDMode(), I never liked that very much, it
> was a hack from the start...
And I didn't add much style to that either :) Adding the indexed code is
useless if there are no other users and I'm not going to clean up the
mess I made in video-dfb anytime soon. Of course, if you'd add just the
SoftOsd bits (without maybe the OSD_WIDTH changes), it would make my
life easier when trying to keep up with cvs updates.
> I also had a quick look at your patch and noticed a bug:
>
> > + // if we have space add it
> > + if (indexedPaletteEntriesFilled < 16) {
> > + indexedPalette[indexedPaletteEntriesFilled] =
> > + orig_palette[i]|0xFF000000;
> > + palette[i] = indexedPaletteEntriesFilled++;
> > + indexedPaletteChanged = true;
> > + }
> > + else { // if no space, try to find a closest match
> > + int closest_i=-1, closest=4*0xFF;
> > + for (int j = 0; j < 16; j++) {
> > + // euclidean distance would be ideal, but too cumbersome
> > + int r = ((uint32_t)orig_palette[i]>>16 & 0x000000FF-
> > + (uint32_t)indexedPalette[j]>>16 &
> > 0x000000FF)&0x000000FF;
> > + int g = ((uint32_t)orig_palette[i]>>8 & 0x000000FF-
> > + (uint32_t)indexedPalette[j]>>8 &
> > 0x000000FF)&0x000000FF;
> > + int b = ((uint32_t)orig_palette[i]>>0 & 0x000000FF-
> > + (uint32_t)indexedPalette[j]>>0 &
> > 0x000000FF)&0x000000FF;
> > + int d = r+g+b;
>
> This doesn't work. Consider orig_palette=126 and indexedPalette=128, the
> difference will be -2=0xFFFFFFFE. So you will add 0xFE=255 instead of 2.
> You either need an abs() or to square the rgb values, I would prefer the
> square.
Yikes. You're right - I was trying to avoid squaring and even abs():ing,
but obviously failed miserably. Of course, like the comment says, that
should be calculated by euclidean distance, but I figured just summing
the component differences is close enough. Thanks for the notice.
-- Heikki Lindholm
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
