Bouncing lines which shouldn't bounce (broken sub-pixel /pos)

[GoogleCodeExporter]

WinXP SP3 x86

See attached script.

This may be a bit hard to see, but xy-VSFilter causes the multiple sub-pixel 
positioned lines in the attached script to bounce, while the same script is 
smooth with VSFilter 2.39. It appears that xy-VSFilter may be rounding up/down 
sub-pixel positioned lines to the nearest pixel, which causes the unwanted 
bouncing.

Original issue reported on code.google.com by cyber.sp...@gmail.com on 24 Sep 2011 at 1:06

Attachments:

• subpixel_positioning.ass

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It's too hard for my eyes to find the difference between the output of VSFilter 
2.39 and xy-VSFilter.
Indeed there is a difference concerning subpixel rasterization. I made it that 
way in purpose, in order to ensure cache efficiency. If that happens to be the 
reason for the issue you seen, then it won't be considered as a bug. Acording 
to my observation, that mod will produce more comfortable effect with a \move 
tag, see attached script. Borders of some strokes keep changing while moving, 
e.g. the strokes of the seventh charater "雲". This annoying artifact 
disaplear with xy-VSFilter. Maybe I'll make a additional option for it so that 
the behavior can be choosed. 

Original comment by YuZhuoHu...@gmail.com on 24 Sep 2011 at 3:05

Attachments:

• 1.ass
• 雲.png

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'll agree that sub-pixel positioning can be in-efficient compared to /move, 
but it does allow for extremely high accuracy typesetting on targets which are 
also moving at sub-pixel rates each frame. The problem is that rarely people 
use it extremely heavily, and you don't have control over how they typeset 
things or create karaoke effects. Since this line was following a sign with 
frame-accuracy and the bouncing/vibrating was very obvious at the end, since 
the video background this was matching was moving in sub-pixel increments and 
you had a reference point of where it should be in the video. Depending on how 
heavily a script uses sub-pixel positioning, this could cause visually 
unpleasing effects to varying degrees.

Overall, sub-pixel positioning is used very rarely in maybe 0.1% of scripts, 
but when it is, it is usually for a reason and it needs to work properly. Is 
the common scenario bad enough for cache efficiency or speed that it's worth 
breaking scripts by default?

It's the same idea as the following web demos:
http://ie.microsoft.com/testdrive/Performance/TextSizeAnimated/Default.html
http://ie.microsoft.com/testdrive/Performance/TextJustificationAnimated/Default.
html
http://ie.microsoft.com/testdrive/Performance/ScrollingText/Default.xhtml

By default in Firefox 6.0 (and IE9), the above tests will be smooth on 
Vista/Win7 if hardware acceleration is enabled. If you go into about:config and 
change
gfx.font_rendering.cleartype_params.rendering_mode = 2
the movement will be jerky and unsmooth in all tests because the above setting 
forces whole-pixel positioning, while the default uses sub-pixel positioning. 
If someone tried to reproduce those tests with xy-VSFilter using sub-pixel 
positioning, they would probably look just as bad.

If you could make it an additional option that would be very appreciated. If 
not, could you please provide a patch, so I could compile my personal builds 
with it enabled if desired?

Original comment by cyber.sp...@gmail.com on 24 Sep 2011 at 9:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just checked the 1.ass you attached, and the upward movement was very 
unsmooth and jerky as well compared to VSFilter 2.39, so this does seem to be 
the same issue. Which means /move is really no improvement as far as smoothness 
goes.

I've attached a clip from the video I first noticed the bouncing problem, which 
should hopefully be easier to see the problem than the standalone script.

Original comment by cyber.sp...@gmail.com on 24 Sep 2011 at 10:24

Attachments:

• bouncing.mkv

[GoogleCodeExporter]

Attached is another clip showing bouncing/vibrating with xy-vsfilter using a 
single line with /move without any explicit sub-pixel positioning.

Original comment by cyber.sp...@gmail.com on 24 Sep 2011 at 11:02

Attachments:

• move_stuttering_subs.mkv

[GoogleCodeExporter]

Original comment by YuZhuoHu...@gmail.com on 26 Sep 2011 at 4:30

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by YuZhuoHu...@gmail.com on 27 Sep 2011 at 12:38

• Changed state: Started

[GoogleCodeExporter]

Fixed. See 
http://code.google.com/p/xy-vsfilter/downloads/detail?name=xy_vsfilter_test_2011
1001.7z&can=2&q=#makechanges

Original comment by YuZhuoHu...@gmail.com on 1 Oct 2011 at 6:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thank you for working on this. Unfortunately, there is a new bug causing 
sub-pixel positioning to always be disabled when opening a video, even when you 
have the correct option set in xy-VSFilter settings.

The only way to get sub-pixel positioning working in by disabling and 
re-enabling the setting when a video is loaded/playing as follows:

'Subpixel Position Level' = 0x1, 0x2, or 0x3
Load a video.
Sub-pixel positioning is not working.
Open VSFilter Settings.
Set Sub-pixel positioning to NONE.
Click APPLY.
Set Sub-pixel positioning to 2x2, 4x4, or 8x8
Click OK.
Sub-pixel positioning is now working.
Close video.
Load a video.
Sub-pixel positioning is not working.
Repeat steps to get it working...

Hopefully this isn't difficult to sort out, since for whatever reason the 
setting isn't initializing properly on video load.

Original comment by cyber.sp...@gmail.com on 1 Oct 2011 at 7:43

[GoogleCodeExporter]

Issue in Comment 12 confirmed fixed in xy_vsfilter_test_20111002.

Original comment by cyber.sp...@gmail.com on 2 Oct 2011 at 3:16

[GoogleCodeExporter]

Original comment by YuZhuoHu...@gmail.com on 5 Oct 2011 at 4:49

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by cyber.sp...@gmail.com on 2 Nov 2011 at 11:33

• Changed state: Verified