#8 frame visible in recording

closed-fixed
None
3
2007-12-01
2007-11-28
No

When you choose to draw a frame around the recording area and also use the mouse-follow feature, the frame shows up in the recording. It is not drawn fast enough so when moving the mouse it lags a little making it enter the current recording area.

It should be ignored or maybe drawn in a video-layer that is not recorded.

Discussion

  • John Varouhakis

    John Varouhakis - 2007-11-28

    Logged In: YES
    user_id=1585344
    Originator: NO

    This is a known problem and it is caused because the frame
    is drawn by the frontend. This means it's position-update
    is asynchronous from that of the capture area.

    >> It should be ignored or maybe drawn in a video-layer that is not recorded.

    There is no sane way to exclude a window that overlaps with the
    recording area, from being captured.

    The only viable solution to this problem is to move the frame drawing
    to the backend, which will make it's movement synchronous to that of
    the capture area.

    I have no ETA for when I'm going to fix this issue.
    I'll come back on it when I have some time.

     
  • John Varouhakis

    John Varouhakis - 2007-11-28
    • priority: 5 --> 3
    • assigned_to: nobody --> iovar
     
  • Matthias Niess

    Matthias Niess - 2007-11-29

    Logged In: YES
    user_id=936564
    Originator: YES

    > I have no ETA for when I'm going to fix this issue.
    > I'll come back on it when I have some time.

    No hurrys ;) I just thought I'd put this in the bug tracker when I stumbled upon it. If s.o. doesn't want the frame in the recording you can still deactivate the frame.. so no problem here.

     
  • John Varouhakis

    John Varouhakis - 2007-12-01

    Logged In: YES
    user_id=1585344
    Originator: NO

    Done (in CVS).

    The frame is now drawn by the commandline program so it never
    enters the capture area and it's size is always correct.

    The interfaces (qt/gtk-recordMyDesktop) have been updated also.
    They still draw their frames before the capture starts
    (to indicate where the capture will be), but these are
    hidden afterwards.

    >> I just thought I'd put this in the bug tracker when I
    >> stumbled upon it

    That was a good thought :)

    Cheers,
    John.-

     
  • John Varouhakis

    John Varouhakis - 2007-12-01
    • status: open --> closed-fixed
     
  • Mike.lifeguard

    Mike.lifeguard - 2009-06-11

    Done in what commit? I want to be sure to grab something without this bug.

     
  • frostinet

    frostinet - 2010-01-19

    I still have that behavior in version 0.3.8.1, but the bug is marked `FIXED' ... any idea?

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks