> I would prefer to move towards a single OSD approach where we used
> fixed width fonts, this should help simplify the painting code and
> make the overall "look" more consistent.
Then please use fixed-pitch TrueType fonts. Raster fonts will look
pixellated after a StretchBlt ... I really don't like granulated captions,
so I'd prefer TrueType that resizes with the screen. Even if we stick
to fixed-width TrueType fonts like Courier New, Verdana, etc.
> I think you get a frame drop each time the screen redraws, this is (to me at least) unacceptable.
It is redrawing 30 times per second, but dropping video only 2 times.
So no, not *every* time....
> > (2) Draw the caption text in surges at a time, not every 1/60 of a second
> We only draw when we get a draw instrction from the CC decode, for pop
> captions these are flip instructions for scrolling they may be more frequent
> but the flashing could eb got round faily easily as has been done for
During scrolling captions during the disaster stuff,
the captions were redrawing something like 30 times per second here,
with each letter appearing on the fly (as it should on a real TV,
using this 'live' scrolling mode). This is completely normal - this
happens on regular TV's. I'm just asking you to buffer the updates
down to only 4 times per second, rather than 30 times per second.
Don't make the updates any slower than 4 times per second, though,
I want to read the text 'live' in the live scrolling mode that most
news TV shows use, not one line at a time!
> OK so what do we need
> I think we need :
> A Screen class that holds the charaters to display, this is a customizable width and height and holds caption characters. It will also reference a code page.
> A Character class that holds colour, and other attributes for each character and an ASCII code for the character
> A codepage class that holds a character bitmap for each ASCII code. Changing the screen size
> will cause the code page to be regenerated when it is first used after that.
> A character bitmap that contains a bitmap of a single character in the format
> Screen Height/OSD Height by ScreenWidth/OSD Width. These should be created
> where possible by using TrueType fonts or by using code to generate an image.
> Does this sound right to you?
More or less. Also make the 'cells' exactly the same pixel width.
I can't remember the CC specification, but I think there are 32 cells
per line (right?) .... This means that the width of the whole captions
would resize in steps of 32 rather than smoothly as the screen resizes,
since each cell must be exactly the same size, for speed.
To compensate for this granularity, center the whole line of 32 cells
horizontally in the middle of the buffer - this will keep the left and
right borders equal. Same goes for the vertical dimension.
I think there's a border gap of approximately 4 cells af the left
and 4 cells at the right that never ever gets text (this is for regular
TV overscan). I don't remember exact spacing from the CC spec, though.
Because we probably don't plan to resize the captions while we adjust
overscan, I suggest keeping this border size configurable
(to shrink/enlarge the caption text grid relative to the video)
to accomodate user preferences and to keep captions aligned with items
on text (in movies, some captions are displayed underneath the character
on the screen)