Heikki Lindholm schrieb: > 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. >
>From you other mail: > I didn't receive the above Martin's message at all - off list, perhaps? > Anyway, if it's still about the topic in question, the keyword for using > the subpicture layer from my perspective is 'incompetence': I couldn't > get crtc2 (mgatv) video layer working with YV12 colourspace and blitted > OSD, so, I thought maybe it'd work with a subpicture layer more > effortlessly, and it did. So, the advantage for me isn't the OSD really, > but the YV12 for the crtc2 video. YV12->YUY2 was simply too slow. > Ah, yes I see. I forgot that for mgatv the default is YUY2, I thought that it is I420. Of course YV12 is faster compared to YUY2... Why is YUY2 is the default at all? Is the OSD not working at all or is only the StrechtBlitting not working? > Using YV12 and LUT44 both bring advantages of reduced memory > requirements and are generally faster. I didn't implement the scaling > routines for the LUT44 OSD, because I simply didn't grasp the idea of > the existing code in 5 seconds, and realized that scaling would > practically never be required by the tv output. > Scaling LUT44 makes not much sense, the quality would be very low because of the limited colors. The simplest and fastest solution one could do, would be to skip or repeat pixels. To adopt the existing scaling routines to indexed bitmaps would be dead slow, and probably still have a limited quality. I saw that you implemented ScaleVUpXXXLut() and ScaleVDownXXXLut(), that is not needed, if you don't scale only a CopyToBitmapLut() should be enough. But without scaling there probably will be complaints again because of the shift of the menu cursor and the menu when using the DVD-plugin. >> 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. > No, either we apply the DFB part and the OSD part together or nothing. I don't want to have some code in the softdevice which is not used and probably never will be used. What I wanted to say is, if you agree with Stefan on the DFB part, I don't mind if we add the OSD part (maybe with some modifications...). Bye, Martin _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
