[MPlayer-dev-eng] [PATCH] Color Support for Blinkenlights Output Module
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Sun Dec 29 23:29:26 CET 2013
On Sun, Dec 29, 2013 at 08:29:44PM +0100, Stefan Schuermans wrote:
> @@ -306,7 +310,8 @@
>
> static int query_format(uint32_t format) {
> if (format == bl->img_format)
> - return VFCAP_CSP_SUPPORTED|VFCAP_CSP_SUPPORTED_BY_HW;
> + return VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW |
> + VFCAP_ACCEPT_STRIDE;
> return 0;
This seems kind of unrelated?
> @@ -330,12 +335,12 @@
> static int draw_slice(uint8_t *srcimg[], int stride[],
> int w, int h, int x, int y) {
> int i;
> - uint8_t *dst = image + y * bl->width + x;
> + uint8_t *dst = image + (y * bl->width + x) * bl->channels;
> uint8_t *src=srcimg[0];
> - // copy Y:
> + // copy Y or RGB data
> for (i = 0; i < h; i++) {
> - fast_memcpy(dst,src,w);
> - dst+=bl->width;
> + fast_memcpy(dst,src,w*bl->channels);
> + dst+=bl->width*bl->channels;
> src+=stride[0];
>
> }
Hm, I was assuming that draw_slice wouldn't normally be used for RGB.
(slightly unrelated): Strangely, it seems that many allocations use a multiplication by a
constant "3" which seems a bit strange.
E.g. what is the point of this:
> bl_size = 12 + bl->width*bl->height*bl->channels;
> bl_packet = malloc(12 + bl->width*bl->height*3); /* space for header and image data */
Same applies to some memset/memcpys. Completely unrelated, I wonder why flip_page introduces a full 1 frame delay,
and even uses a full memcpy to do so (which is silly either way, double-buffering would make a lot more sense,
if I could see any sense in the delay in the first place).
I suspect that a bit of code cleanup wouldn't hurt, even though that probably isn't as much fun as
watching colourful LEDs ;-)
More information about the MPlayer-dev-eng
mailing list