ma, 2006-09-18 kello 18:44 +0200, Martin Wache kirjoitti: > 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
Don't ask me. > > 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 That's true. 2x and (1/2)x scaling might be passable. > 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. What does the DVD plugin do? I haven't tried that one (either). > >> 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 Firm but fair. I'm not going for that, for now, then. Maybe I'll update the patch sometime and re-post. -- Heikki Lindholm _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
