jcs Reporter
	Description • 11 years ago

When scrolling through paragraphs of text, occasionally the text will be redrawn with artifacts over it that look like it's been bolded, but when scrolling that area of text off the page, raising another window over it, or reloading the page, the text will be returned to normal.

Just as I was entering this bug, the problem showed each time I would make a spelling mistake and this text box had to be redrawn with the red underline.  If I hit backspace to erase the red underline, then hit space, the text above would get bolder.  If I did that a few times in a row, the text would get even bolder.

This problem has been reported by at least a few different OpenBSD users and appears to have started after 17.0.  It is not reproducible in 17.0 or lower, and is still present in 19.0.2.  I have tried various versions of Freetype with no change, and am currently using 2.4.11.

It is reproducible with different fonts (system or web) and on different sites.

	jcs Reporter
	Comment 4 • 11 years ago

I've attached three screenshots showing normal text with a hit-a-hint extension drawing over links (an easy way to reproduce the problem), the same text after dismissing the hit-a-hint which shows slight artifacts, and then after repeating it a number of times showing extreme artifacts.

	Darren Johnston
	Comment 5 • 11 years ago

Here is a video of the issue: http://www.youtube.com/watch?v=I4CFjyv39VQ
I am unsure if this is just related to freebsd and/or possibly a dependency?

	Darren Johnston
	Comment 6 • 11 years ago

possibly related to zindex?

	Landry Breuil (:gaston)
	Comment 7 • 11 years ago

openbsd, not freebsd. And the issue on the youtube video seems different from the issue we're seeing here.

	Darren Johnston
	Comment 8 • 11 years ago

well I'm on freebsd and I have exactly the same issue.

	Darren Johnston
	Comment 9 • 11 years ago

I think this may have caused the issue:  https://bugzilla.mozilla.org/show_bug.cgi?id=814101

	Darren Johnston
	Comment 10 • 11 years ago

about:config
gfx.xrender.enabled;false
seems to fix the problem.

which then solely puts the issue at the bugfix above.

	Jan Beich
	Comment 11 • 11 years ago

(In reply to Darren Johnston from comment #10)
> gfx.xrender.enabled;false
> seems to fix the problem.

helps only in combination with layers.acceleration.force-enabled (Nightly here)

The issue happens with just xrender disabled or just gl layers enabled and with different cairo versions (1.10.2 and 1.12.14). What changes is place/time to reproduce: hint-or-hint, navigating editbox, moving in history, scrolling, etc.

	Darren Johnston
	Comment 12 • 11 years ago

(In reply to Jan Beich from comment #11)
> (In reply to Darren Johnston from comment #10)
> > gfx.xrender.enabled;false
> > seems to fix the problem.
> 
> helps only in combination with layers.acceleration.force-enabled (Nightly
> here)
> 
> The issue happens with just xrender disabled or just gl layers enabled and
> with different cairo versions (1.10.2 and 1.12.14). What changes is
> place/time to reproduce: hint-or-hint, navigating editbox, moving in
> history, scrolling, etc.

flipped gfx.xrender.enabled:true
and layers.acceleration.force-enabled

The artifacts are still there, but at a lesser rate.  I can live with it now =)

	Jan Beich
	Comment 13 • 11 years ago

I guess bug 709477 wasn't fixed or regressed upstream. After building
gfx/cairo as shared library and LD_PRELOAD'ing the artifact is gone.

xlib-glyph-clip-region.patch still applies fine on freebsd where we're
using cairo-1.10.2 in the ports tree.

	Landry Breuil (:gaston)
	Comment 14 • 11 years ago

Happens with systemwide 1.12.4 here, and xlib-glyph-clip-region.patch doesnt apply against it.
 
gfx/cairo/README mentions 'xlib-glyph-clip-region.patch: bug 709477, addressed upstream by be1ff2f45fdbc69537e513834fcffa0435e63073', but the upstream commit (http://cgit.freedesktop.org/cairo/commit/?id=be1ff2f45fdbc69537e513834fcffa0435e63073) looks different.

	vcunat
	Comment 15 • 11 years ago

I'm having exactly the same issues on a *Linux*, after switching on system-cairo. It's firefox-21.0, cairo-1.12.14 (xcb enabled), freetype-2.4.11 with infinality patches.

I'll be glad for any pointers (feel free to ask for info, rebuild against different settings, etc.).

	Landry Breuil (:gaston)
	Comment 16 • 11 years ago

(In reply to vcunat from comment #15)
> I'm having exactly the same issues on a *Linux*, after switching on
> system-cairo. It's firefox-21.0, cairo-1.12.14 (xcb enabled),
> freetype-2.4.11 with infinality patches.
> 
> I'll be glad for any pointers (feel free to ask for info, rebuild against
> different settings, etc.).

And is it okay when built against the bundled cairo lib ? We have the same cairo/xcb setup on OpenBSD.

	vcunat
	Comment 17 • 11 years ago

Yes, up to now our setup was the same but for internal cairo (I don't know what version/config it has) and this issues didn't happen.

	vcunat
	Comment 18 • 11 years ago

Perhaps I should stress that to make it compile with system cairo, I had to apply patch from https://bugzil.la/722975.

	vcunat
	Comment 19 • 11 years ago

Another important thing may be that we use subpixel smoothing by default in freetype. Even with system cairo firefox/thunderbird does *not* render with subpixel smoothing (unlike all other apps), but still IMHO it does look better than with the internal cairo. Better font rendering was the main reason I was trying this change (besides non-shared libs being ugly and non-UNIX style).