We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Created attachment 332 [details]
A small C source: Demonstrates Bug 640

Program writes 480x640 YUYV image at overlay->pixels[0] of a 480x672 surface and overlay. Upper 576 lines display correctly; the 96 lines below show a flickering copy of the top 96 lines of the image. Usage: Click below 640 to quit

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

I'm not seeing the issue with your bug...

The code you attached creates a 480x672 screen and overlay, and then you only fill in the top 640 pixels in the overlay, which leaves uninitialized garbage there.

The output is as expected, a slow fill from the top down to the garbage area, repeated.

Am I missing something?

It sounds like gatekeeper's issue is resolved in SDL 1.3.

Here's the full reply:

The background to the bug report is this

Recent linux kernel releases (ie Opensuse11) have a new driver for USB SPCA compat. webcams. I still use low-res webcams sometimes for watching wildlife as I live in rainforest on east coast of australia. I use a digital camera more these days

The new driver is gspca and the old was spca5xx

The main display utility was changed from spcaview to luvcview
and differs in using the v4l interface to the driver instead of videodev ioctls

All these are maintained by Michael Xhaard

spcaview had a separate child-thread panel for camera control
but luvcview displays a 32 pix high inline graphic of buttons
that is scaled to width for 640x480 and 320x240 formats
on the same surface that gets the video overlay
luvcview retains a child-thread for mouse-event handling which is unnecessary
and adds complexity

One of the $5 generic webcams that I have a few of (zc0307) has
a large clothes peg that makes attaching it to a shelf easy
but sometimes I only have a verticle edge to clip onto

So I modify viewer programs to rotate the image so 480x640

luvcview with 32 lines for the controls is 480x672 with top 640 lines
displaying video

spcaview uses memcpy to transfer video from buffer to display (which is double-buffered)
and had no problem with displaying 640 lines
whereas luvcview which uses DisplayYUVOverlay truncated the video when displaying 480x640 + 480x32.
My recollection is it's a random length transfer, longer at low framerate

The program I submitted is the luvcview viewer cut back to minimum
that shows the problem, which was with  SDL v1.2 but not v1.3

The YUV video data was replaced by generated YUV to drop the driver
and camera and v4l out of the act

I upgraded to SDL v1.3 which does the DisplayYUVOverlay properly.

luvcview had to be changed to use PollEvent not WaitEvent for the mouse

By the time I had got through it all I realized that no other SDL v1.2 user
would be likely to spot the problem so it would be a waste of effort fixing it

Instead I sent Sam a note or patch about opensuse11 having a novel path
to X11.h that needed adding to the paths in .configure for libSDL v1.3
and notified M Xhaard about the change to mouse event handling
that would be needed for compatibility with libsdl v1.3 

see also attached section of my log of the time

finally: the documentation
sources xml but I get html when checkout the sources from svn

i hand-edited html pages for most of the new functions in v1.3
mainly from the comments in the header files (mostly just the functions
and their arguments and return values) and changed all pages so the
next/prev links work

i guess the xml sources are maintained with a xml text processor
and a set of templates and not in a vc repository

i can send you the html or i could have a go at the xml with a bit of instruction
I'm a 65 year old pensioner with a fair bit of spare time when its raining

cheers,
Ron