summaryrefslogtreecommitdiff
path: root/gtk-recordmydesktop/po/Makefile.in.in
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2020-06-19 12:24:31 -0700
committerVito Caputo <vcaputo@pengaru.com>2020-06-20 15:59:59 -0700
commit1c4174855664744595541347afecfea1fb919b52 (patch)
tree07f52cff8bec78526e28be5bcccbb6610884f143 /gtk-recordmydesktop/po/Makefile.in.in
parentb8bc8eaf02d19b5739df3797100b4b5d12d8fbbc (diff)
setbrwindow: yank nbytes out of BRWindow struct
This only gets used in one place and isn't even relevant for shmem scenarios where the size in bytes depends on the bytes per row from the server. For now I'm just moving its simple computation to where it's used, as-is. It seems to be doing some 16-byte alignment dance as well which... seems very odd. If the sizes were already getting 16-byte aligned, why do this again? I fully expect to throw the alignment shit out at some point, as this all gets reworked. The way this was done seems completely misguided... the Theora alignment considerations should be handled in the YUV buffer, since the copy needs to be made from the XImage in all cases - shmem and non, to convert to YUV, the YUV buffer should have been sized to accomodate Theora, and the RGB->YUV conversion-copy should pad out the aligned target buffer as needed.
Diffstat (limited to 'gtk-recordmydesktop/po/Makefile.in.in')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved