The FreeType Project - Bugs: bug #58373, Half pixel glitching
You are not allowed to post comments on this tracker with your current authentication level.
bug #58373: Half pixel glitching
Submitter: | - <_194785> | ||
Submitted: | Fri 15 May 2020 01:29:11 PM UTC | ||
Severity: | 1 - Wish | Item Group: | Incorrect behaviour |
Status: | Ready For Test | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Planned Release: | 2.10.3 |
Jump to the original submission
Tue 17 Nov 2020 08:53:02 PM UTC, comment #41: |
Anonymous |
Mon 16 Nov 2020 09:41:19 PM UTC, comment #40: As TD renderer gets updated, it starts to develop complexity and performance issues.
|
Anonymous |
Wed 11 Nov 2020 07:32:26 PM UTC, comment #39: Riglos Mono 1.4 has deliberate incompatibility and counterclockwise rectangles on half pixel outlines are a part of that incompatibility.
|
Anonymous |
Sat 26 Sep 2020 05:52:13 PM UTC, comment #38: Discuss what the best Quadratic Formula for Pixel Building is at https://pixelbuilding.createaforum.com/quadratic-pixel-building/quadratic-formula/
|
Anonymous |
Mon 21 Sep 2020 06:36:02 AM UTC, comment #37:
|
Anonymous |
Sun 20 Sep 2020 07:07:01 PM UTC, comment #36: Piotr,
|
Alexei Podtelezhnikov <podtelez> |
Sun 20 Sep 2020 05:16:29 PM UTC, comment #35:
|
Anonymous |
Sun 20 Sep 2020 05:07:34 PM UTC, comment #34: Piotr,
|
Alexei Podtelezhnikov <podtelez> |
Sun 20 Sep 2020 04:09:20 PM UTC, comment #33: And by a right hand rule
|
Anonymous |
Sun 20 Sep 2020 03:58:49 PM UTC, comment #32: If anything, the specification might have a bug, not the renderer. It was likely the intent that a half pixel boundary doesn't turn the pixel on, but makes the winding value the higher value out of the two sides, and 0 is larger than -1 so the background is the value. The specification used bad wording but it's entirely unnecessary to take that literally. |
Anonymous |
Sun 20 Sep 2020 03:55:11 PM UTC, comment #31: Please implement Six Pass Pixel Building to properly render half pixels of inside out shapes such as counters. |
Anonymous |
Sun 20 Sep 2020 03:47:19 PM UTC, comment #30:
|
Anonymous |
Sun 20 Sep 2020 03:37:12 PM UTC, comment #29:
|
Anonymous |
Sun 20 Sep 2020 11:48:29 AM UTC, comment #28: $.PNG might demonstrate a bug in GDI. Notwithstanding that the top-right box has the wrong counter-clockwise orientation, the border pixels are inside according to Rule 2. |
Alexei Podtelezhnikov <podtelez> |
Sun 20 Sep 2020 04:57:35 AM UTC, comment #27:
|
Anonymous |
Sat 19 Sep 2020 10:27:07 PM UTC, comment #26: FreeType git HEAD now renders the box from comment #24 and boxy Riglos Mono font correctly.
|
Alexei Podtelezhnikov <podtelez> |
Sat 19 Sep 2020 05:48:12 PM UTC, comment #25:
|
Anonymous |
Sat 19 Sep 2020 05:10:15 PM UTC, comment #24: This is how six pass Pixel Building looks like, and TD renderer uses it starting with version 2.0 . TD renderer 1.0 was glitched due to not implementing the last two passes, and FreeType is glitched because none of the passes are implemented properly.
|
Anonymous |
Sat 19 Sep 2020 04:53:15 PM UTC, comment #23: Note the Quadratic Formula:
|
Anonymous |
Sun 13 Sep 2020 06:12:09 PM UTC, comment #22: A fix is committed. |
Alexei Podtelezhnikov <podtelez> |
Fri 11 Sep 2020 08:59:44 PM UTC, comment #21: It is hard to handle horizontal lines in vertical sweep because they have ambiguous intersection profile when aligned to pixel centers. To demonstrate the bug
|
Alexei Podtelezhnikov <podtelez> |
Mon 24 Aug 2020 11:01:28 AM UTC, comment #20: In Half pixel glitching — standard rendering and subpixel rendering.PNG it is demonstrated that when the render modes are properly simulated (because in both render modes vertical anti-aliasing can be disabled by the gasp table) FreeType rendering results in Half pixel glitching in both render modes.
|
- <_194785> |
Thu 13 Aug 2020 07:48:00 AM UTC, comment #19:
|
- <_194785> |
Wed 12 Aug 2020 01:56:30 PM UTC, comment #18:
|
Alexei Podtelezhnikov <podtelez> |
Wed 12 Aug 2020 01:00:46 PM UTC, comment #17: It is also important to note that every Microsoft renderer as far as I know is based on the bilevel renderer. So simulating any Microsoft renderer with the FreeType renderer, the bilevel glitches will pop up in all of them for some inputs, where each glitched bilevel pixel corresponds to an incorrectly sampled fraction of a pixel. So, it really affects both bilevel rendering and grayscale rendering, when using oversampled anti-aliasing. Any bilevel glitching is therefore extremely important for the purposes of software preservation. The anti-aliasing, which a font doesn't even have to enable, should not distract from the glitching in the bilevel renderer, which is the very main core of rendering. The bilevel renderer is an inseparable part of TrueType rendering. |
- <_194785> |
Wed 12 Aug 2020 12:27:29 PM UTC, comment #16: I just want to say thank you Piotr for reporting this bug: reporting bugs take time, and you did an amazing job of describing this one in detail, so that perhaps it can be fixed in the future. This is beneficial to the whole open source community. Thank you.
|
Boris Dalstein <dalboris> |
Tue 19 May 2020 06:30:42 PM UTC, comment #15:
This bug does not complain about its own priority, it complains about something unrelated to the priority itself. Therefore it is off-topic.
What are you talking about? I do not know any of FreeType's code because it is completely immense and I did not write a single character of it, therefore there's no way I'm supposed to know what any piece of FreeType's code specifically does. |
- <_194785> |
Tue 19 May 2020 06:10:50 PM UTC, comment #14: I have only tried to explain to you why your bug is low priority, The bug priority is on-topic, of course.
|
Alexei Podtelezhnikov <podtelez> |
Tue 19 May 2020 05:54:41 PM UTC, comment #13:
|
- <_194785> |
Tue 19 May 2020 05:43:02 PM UTC, comment #12:
|
Alexei Podtelezhnikov <podtelez> |
Tue 19 May 2020 05:17:20 PM UTC, comment #11:
Riglos Mono 1.1 does not allow anti-aliasing in the gasp table. And this specific bug is for the bilevel rasterizer. But the rasterizer by itself doesn't make it a glitch or not, it's the entire setup that shows the rendering glitch. Changing the rasterizer changes the entire glitch and makes it invalid, like changing 2=2 to 3=2. Anti-aliasing is completely off-topic for this glitch.
This is like comparing apples to oranges.
You can't expect to make the bug invalid by changing it. The Microsoft TrueType renderer is considered the reference bilevel renderer because many fonts are designed to run on the Microsoft renderer. Please stop going off-topic because you could be wasting time. |
- <_194785> |
Tue 19 May 2020 04:13:34 PM UTC, comment #10:
|
Alexei Podtelezhnikov <podtelez> |
Tue 19 May 2020 03:50:33 PM UTC, comment #9:
That doesn't make any sense. Riglos Mono 1.1 disables anti-aliasing in all sizes as seen in the gasp table. A rendering glitch is a rendering glitch, no matter what the renderer mode is, no matter what the renderer mode is supposed to be, no matter what rendering mode is trending.
Are you being sarcastic?
|
- <_194785> |
Sun 17 May 2020 06:35:38 PM UTC, comment #8: I trust that you identified the bug correctly. I hope you realize that this these renderers were cool more than 20 years ago. The world has moved on to anti-aliasing since.
|
Alexei Podtelezhnikov <podtelez> |
Sun 17 May 2020 06:06:34 PM UTC, comment #7: This is the current comparison. https://i.imgur.com/xFhqMRY.png . TD renderer as of version 2.0 is now pixel-for-pixel identical to GDI rendering in this particular font configuration, but is off-topic for FreeType development. The Half pixel glitching in FreeType is yet to be officially verified. |
- <_194785> |
Sat 16 May 2020 07:28:08 PM UTC, comment #6:
|
- <_194785> |
Sat 16 May 2020 01:18:10 PM UTC, comment #5: I was talking about SCANTYPE.
|
Alexei Podtelezhnikov <podtelez> |
Fri 15 May 2020 07:31:42 PM UTC, comment #4:
|
- <_194785> |
Fri 15 May 2020 07:25:18 PM UTC, comment #3: |
- <_194785> |
Fri 15 May 2020 06:57:31 PM UTC, comment #2: |
Alexei Podtelezhnikov <podtelez> |
Fri 15 May 2020 06:30:32 PM UTC, comment #1: Piotr,
|
Alexei Podtelezhnikov <podtelez> |
Fri 15 May 2020 01:29:11 PM UTC, original submission:
I found a glitch named Half pixel glitching. What happens is that in some half pixel structures, FreeType marks pixels blank incorrectly.
|
- <_194785> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 11 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-11-11 | None | Attached File | - | Added Half@pixel@glitching@—@counterclockwise@rectangles@in@deliberate@incompatibility.PNG, #50252 | |
2020-09-20 | None | Attached File | - | Added TrueTypefonttest2.ttf, #49824 | |
Attached File | - | Added $.PNG, #49825 | |||
Attached File | - | Added $FT.PNG, #49826 | |||
Attached File | - | Added SPBB$.PNG, #49827 | |||
2020-09-19 | None | Attached File | - | Added SPPB.PNG, #49820 | |
2020-09-13 | podtelez | Status | None | Ready For Test | |
2020-09-11 | podtelez | Attached File | - | Added half_pixel_1.diff, #49789 | |
Planned Release | None | 2.10.3 | |||
2020-08-24 | _194785 | Attached File | - | Added Half@pixel@glitching@—@standard@rendering@and@subpixel@rendering.PNG, #49701 | |
2020-05-19 | podtelez | Severity | 3 - Normal | 1 - Wish |
Powered by Savane 3.13-f8d8.
Corresponding source code
While VCPB does save processing power in the rendering phase compared to SPPB, it also introduces a similar amount of processing power overhead in the outline generation phase required to generate virtual coordinates and vertical extrema, cancelling out the performance. However, it is still worth it considering the rendering accuracy improvements it has.