Comment 13 for bug 141379

> The difficult part with writing a video widget is to do the "bit
> blitting" to the actual window. In other words, use a raw in memory RGB
> (or YUV) data and draw this to screen. Tk uses an abstract data type
>
> Drawable d;
>
> to describe the destination context. Only on X11 is this something real.
> On Windows it looks like
>
> TkWinDrawable *twdPtr = (TkWinDrawable *) d;
>
> where TkWinDrawable is a struct which also contains a bitmap.handle.
> On MacOSX it looks like
>
> CGrafPtr port;
> port = TkMacOSXGetDrawablePort(d);
>
> and then it is possible to draw raw image data using something like:
>
> PathSetUpCGContext(port, &cgContext);
> ...
> provider = CGDataProviderCreateWithData(NULL, block.pixelPtr, size, NULL);
> colorspace = CGColorSpaceCreateDeviceRGB();
> cgImage = CGImageCreate(block.width, block.height,
> 8, /* bitsPerComponent */
> block.pixelSize*8, /* bitsPerPixel */
> block.pitch, /* bytesPerRow */
> colorspace, /* colorspace */
> alphaInfo, /* alphaInfo */
> provider, NULL,
> 1, /* shouldInterpolate */
> kCGRenderingIntentDefault);
> ...
> CGContextDrawImage(context->c, CGRectMake(0.0, 0.0, width, height), cgImage);
>
> Code from TkPath. I see now that all QuickDraw (CGrafPtr) code need to
> go away for 8.5 since Daniel has replaced everything with CoreGraphics.
>

I'm not able to understand this Tk stuff :O. I'll read it calmly this weekend.

> Bottom line: This will need a great deal of platform dependent code. The
> SDL sources contain tons of examples but the problem is to understand
> them. I guess we only need to implement this for the special case of
> RGB32 or YUV formats. That should be easier. It is like drawing a tk
> image in TkPath.
>

Until next week I've not been able to work again in the video stuff. Sorry.