zoom anomaly on raptor
Posted: 09 Jun 2009 09:33
Hey again,
This is here because unable to get to trac system, greeted by broken python script every try. My last visit there (to add comments to ticket) resulted in what I thought was destruction of the ticket, so don't know what its status is currently, but do know the "zoom crash" is gone.
Skins2 ref trac ticket #2821
VLC-1.0.0-rc3 and cross-check w latest VLC-1.1.0-git
On Goldeneye zoom operation, the resulting video display / UI appears influenced by zoom factor, default vout dimensions / anchor points, default video AR, and another (1 or more) parameter(s) that appear to add padding to the X / Y dimensions of the video, the effects of which are an increase of the default video dimensions, black bars accompanying the video, abnormal increase in the overall UI size.
This fault always occurs on zoom, easily measured (pixel-wise) during initial video-play, then running thru the zoom range, returning to supposed 1:1 state, always predictably larger that initial 1:1 state @ startup.
For lack of a better words, this "padding" appears to be derived from both, vertical and horizontal space to either side of the vout. Both X and Y axis are affected, being skewed (bar size, X or Y) directly by the larger of either horizontal and/or vertical space bordering the Vout.
Example w "raptor-skin", enclosing, 2 pixel, vout borders removed to facilitate direct measurement. Tested using only the the maxl-layout (screen) as the alternate layout (combo), vout is offset in both directions.
NORMAL:
Video default AR: 640x272 (2.35:1)
Vout=640x272=Video AR during play (1:1)
horizontal sides, 11 pixels each, vout / video centered about Y-axis
vertical sides 10 pixels top, 57 pixels bottom, vout offset to the top, video centered about vout X-axis, above center of UI X-axis
UI=662x339
ZOOMED:
Video AR: 662x282 (limited by default AR and still 2.35:1)
Vout=662x339 the difference in size about (vout/video centerline) the X-axis=57 pixels (original size of bottom side of UI), now split, producing the black bars, filling the rest of vout. Horizontal resizing=22 pixels=the sum of left/right sides.
UI=684x406
On Grishenko, this anomaly is not observable, and measures 0 differential, always returning to the original 1:1 state...the default video AR.
black
This is here because unable to get to trac system, greeted by broken python script every try. My last visit there (to add comments to ticket) resulted in what I thought was destruction of the ticket, so don't know what its status is currently, but do know the "zoom crash" is gone.
Skins2 ref trac ticket #2821
VLC-1.0.0-rc3 and cross-check w latest VLC-1.1.0-git
On Goldeneye zoom operation, the resulting video display / UI appears influenced by zoom factor, default vout dimensions / anchor points, default video AR, and another (1 or more) parameter(s) that appear to add padding to the X / Y dimensions of the video, the effects of which are an increase of the default video dimensions, black bars accompanying the video, abnormal increase in the overall UI size.
This fault always occurs on zoom, easily measured (pixel-wise) during initial video-play, then running thru the zoom range, returning to supposed 1:1 state, always predictably larger that initial 1:1 state @ startup.
For lack of a better words, this "padding" appears to be derived from both, vertical and horizontal space to either side of the vout. Both X and Y axis are affected, being skewed (bar size, X or Y) directly by the larger of either horizontal and/or vertical space bordering the Vout.
Example w "raptor-skin", enclosing, 2 pixel, vout borders removed to facilitate direct measurement. Tested using only the the maxl-layout (screen) as the alternate layout (combo), vout is offset in both directions.
NORMAL:
Video default AR: 640x272 (2.35:1)
Vout=640x272=Video AR during play (1:1)
horizontal sides, 11 pixels each, vout / video centered about Y-axis
vertical sides 10 pixels top, 57 pixels bottom, vout offset to the top, video centered about vout X-axis, above center of UI X-axis
UI=662x339
ZOOMED:
Video AR: 662x282 (limited by default AR and still 2.35:1)
Vout=662x339 the difference in size about (vout/video centerline) the X-axis=57 pixels (original size of bottom side of UI), now split, producing the black bars, filling the rest of vout. Horizontal resizing=22 pixels=the sum of left/right sides.
UI=684x406
On Grishenko, this anomaly is not observable, and measures 0 differential, always returning to the original 1:1 state...the default video AR.
black