diff options
| author | Vito Caputo <vcaputo@pengaru.com> | 2020-06-19 12:24:31 -0700 |
|---|---|---|
| committer | Vito Caputo <vcaputo@pengaru.com> | 2020-06-20 15:59:59 -0700 |
| commit | 1c4174855664744595541347afecfea1fb919b52 (patch) | |
| tree | 07f52cff8bec78526e28be5bcccbb6610884f143 /recordmydesktop/src/rmd_setbrwindow.c | |
| parent | b8bc8eaf02d19b5739df3797100b4b5d12d8fbbc (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 'recordmydesktop/src/rmd_setbrwindow.c')
| -rw-r--r-- | recordmydesktop/src/rmd_setbrwindow.c | 4 |
1 files changed, 0 insertions, 4 deletions
diff --git a/recordmydesktop/src/rmd_setbrwindow.c b/recordmydesktop/src/rmd_setbrwindow.c index 7b5b862..837d597 100644 --- a/recordmydesktop/src/rmd_setbrwindow.c +++ b/recordmydesktop/src/rmd_setbrwindow.c @@ -189,9 +189,5 @@ boolean rmdSetBRWindow( Display *dpy, brwin->rrect.x,brwin->rrect.y, brwin->rrect.width,brwin->rrect.height); - brwin->nbytes= (((brwin->rrect.width+15)>>4)<<4)* - (((brwin->rrect.height+15)>>4)<<4)* - ((specs->depth==16)?2:4); - return TRUE; } |