| Age | Commit message (Collapse) | Author |
|---|
|
Formally making first release since forking, I'm sure there are bugs
but I doubt anyone will be inclined to help test any of this if there's
nothing at least stating it's a newer version and some mention of the
user-visible changes.
|
|
Just some quick modifications to reflect the forked status
|
|
This restores the recordmydesktop/ subdir as root from the mirror I
cloned by fork from.
I have no particular interest in the gtk/qt frontends and it doesn't
appear they were part of a single tree in the past. But I will
probably preserve backwards compatibility of the cli so they can
continue to work with this fork installed.
|
|
This isn't tested as I don't currently have a JACK setup, but it
at least compiles and looks semi sane.
|
|
Nothing functionally changed
|
|
Nothing functionally changed
|
|
Nothing significant changed
|
|
This may just be ffmpeg ogg decoding bugs, but it requires
investigation to confirm. The playback does show corruption
in mpv/vlc in my testing, but that problem existed pre-fork
as well.
|
|
Nothing significant changed
|
|
With no rrect alignment adjustment happening, there's no need for this
fuckery anymore. The theora encoding offsets will always be left at
0, the frame_{width, height} will clip to rrect.{width,height}, and
the yuv buffer dimensions are the only thing 16x16 aligned.
|
|
rrect of any size/place should be perfectly usable now
|
|
|
|
|
|
Minor cleanup
|
|
Nothing functionally changed
|
|
nothing functionally changed
|
|
nothing functional changed
|
|
Nothing functionally changed
|
|
Assume rects that come in for insertion are already as aligned as
possible within the rrect bounds. If the rrect has odd dimensions,
then there's potential for edge case odd rects too - but the only
even-sensitive code is the YUV updating and that's been amended to
at least ignore those edge cases gracefully.
Also constify the supplied xrect while in here.
|
|
The current rectinsert code does this, but it does it in the absolute root
window coordinate space.
In preparation for dropping all the alignment stuff out of rectinsert, do
the alignment at the rectinsert caller and do it in the rrect-relative
coordinate space.
|
|
Eliminate some pointless duplication
|
|
Just some sanity checks to ensure clipping is working properly
|
|
More tidying of things
|
|
No need to duplicate this down at the teardown, it won't go away
with outstanding references so you can basically queue the rm.
|
|
Baby step towards encapsulating the shmem and ximage state
|
|
More preparation for yuv and rrect dimensions differing
|
|
Nothing significant
|
|
minor formatting/whitespace changes
|
|
No idea why this had such a large type, its members just hold 0 or 1.
|
|
This is temporary, in preparation for potentially odd-dimensioned
image buffers.
For now I'll just skip the last row / column in the UV update for such
odd dimensions.
In the future there could be a read-modify-write dance for handling the
last row/column or something like that.
|
|
This needs to maintain dirty blocks in the yuv frame coordinates,
not in the captured image's cooridinates.
The existing code assumes those are the same in double-buffer mode
where the dirty block tracking is applied. But I'm working towards
allowing the captured image dimensions to be free from the 16x16
alignment constraints the yuv buffers must conform to for theora.
To handle that future, the block coordinates should at least use
the (yuv)->y_width, not width_tm. I also added shifting the x,y
but in double-buffer mode that shouldn't actually be needed since
it'd always be full-shots unless I'm mistaken.
|
|
Nothing really changed here, just rearranging some stuff and
replacing some divides with shifts.
|
|
No idea why rmdGetZPixmapSHM() is doing this, the whole point of
shmem is to not have to read the data over the wire. You request
the server to do the copy into the shared memory and that's all
there is to it.
This program is so confused
|
|
Remove more pointless code
|
|
XCreateImage() returns a fully initialized ready-to-use XImage,
I have no idea why the author did this.
|
|
nothing functionally changed
|
|
nothing functionally changed
|
|
nothing functionally different
|
|
|
|
nothing functionally changed
|
|
Mostly mindless whitespace fixups but also changed some yuvblocks
indexing that seemed brain damaged to just be simpler without
actually changing anything functionally
|
|
This explains why I've seen errors using --long arguments consistently
even for --x and --y. I had assumed --x and --y weren't supported but
it turns out it's just what looks to be a copy and paste error.
Man this source has been such a disaster area.
|
|
nothing functionally different
|
|
|
|
Zero reason for this to be an unreadable macro, make
function and try format sanely
I didn't really change it other than passing the clip rect instead
of brwin
|
|
Convert macro to function and format retained macro portion
|
|
again leaving libjack related stuff for later
|
|
leaving the libjack related fixes for later
|
|
Just simplifying this function to not need brwin-> everywhere while
cleaning up the formatting
|
|
Nothing really changed here, but I suspect the {row,column}_end + 1
conditions in rmdBlocksFromList() are buggy and shouldn't have
the +1. Left as-is for now.
|
