On Tue, 7 Jun 2005, J. Donavan Stanley wrote: > Andy, > > I've not seen anything happening with your chroma OSD patch lately. > Have you updated it to work with DTKs recent changes? Are you and DTK > still working out the details?
I have to admit that a shiny thing :-) distracted me temporarily. DTK gave me the info I needed (I think) to more tightly integrate it with his updated XvMC code, but as I was contemplating my attack plan (his work effectively made the OSD/XvMC interaction alot more complex) I got distracted. The upside for me is that Daniel's work seems to have stabilized while I was looking the other way, so I should have less trouble keeping my codebase current while I work on it. There are basically four tasks involved: 1) re-integrate the paint-unused-squares functionality so that the COSD can use any chromakey color while still providing a black (or even user-configurable color to avoid burn-in) surround (letter- and/or pillar-boxes around the video) if necessary 2) make it runtime configurable (I have zero experience here so it's likely to be rough going) 3) integrate the OSD evaluation and display with the new XV/XvMC code 4) document how to generate OSD themes compatible with the COSD and provide at least one working example (also not a strength for me) On #1, there is a decision to be made here. Presently, the COSD forces 0x01 as the chromakey color and thus black (0x00) is the "transparent" color in the OSD theme. Daniel suggested using some unlikely color (like pure blue) as the transparent color in the OSD theme, and then mapping (re-writing?) that to the chromakey color on the fly in the COSD. I'm concerned that will lead to increased cpu usage, and un-do some of the performance gains the COSD provides. As I recall, his request stemmed from a concern that, if run on a desktop and not in fullscreen mode, other windows on top of the video playback background window are likely to have black in them, and thus "trip over" the chromakey. I've convinced myself that this is not a supported activity, and that the video background window should always be on top, and thus it really shouldn't matter what colors any other window is using since we should never encounter them as a background to the video. Daniel, please correct me if I've botched my interpretation of your concern. Am I off base here? It seems like a good bit of additional coding and execution effort to support what seems to me to be an un-important (perhaps even virtually impossible) situation. I anticipate getting over a big hump in this other project (the afore-mentioned shiny thing) this weekend, so I should get back to work on this next week. -Andy
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
