Summary: | Fill don't work properly | ||
---|---|---|---|
Product: | cairo | Reporter: | marco <marcofal> |
Component: | xlib backend | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED NOTABUG | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | minor | ||
Priority: | medium | ||
Version: | 1.4.14 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Screenshot of strange fill behavior
photo of lcd rendering |
Description
marco
2008-06-03 00:32:00 UTC
Works for me with latest cairo and with 1.6.4. 1.4.x is unsupported. While it's true that 1.4 is unsupported, a simple case like this should work equally fine in 1.4 and 1.6. And, in fact, I can't see any difference between the 1.4 and 1.6 behavior for this case. So, now, can you give us more information on what you're seeing wrong with this example? Here's one guess I have: Are you viewing the result on an LCD monitor? And do you perceive a "darkish seam" on the right-side boundary between the red and blue colors? But no similar dark seam on the left side? And no similar seam between red and yellow? If so. Is this darkness not caused by an actual gap of an unlit green subpixel element in the LCD between the red and blue subpixels? I've checked the final color values on the left and right sides and they seem equivalent to me. Let me know if I'm totally off in my guesswork here. -Carl Yeah, doesn't help that there's no screenshot of the broken output attached.. Created attachment 16892 [details]
Screenshot of strange fill behavior
Hi,
sorry for my careess, here is the screenshot...
marco
Comment on attachment 16892 [details]
Screenshot of strange fill behavior
I use a CRT monitor, at home and at work, the video card is nvidia gf7300, xorg version 7.2 at home, intel 833 and xorg 7.1 at work, with same output.
Created attachment 16894 [details]
photo of lcd rendering
I took two macro photos of your screenshot on my lcd, at about 17000dpi (resized down to about 4500dpi in the attached image).
The left side shows the left border of the ellipse, with a blue pixel to the left of the red pixel. The subpixels are "rgBRgb" with capital letters being on and small off. So, the blue and red regions touch perfectly.
The right side of the image shows the right border of the ellipse, with a red pixel to the left of a blue pixel. Here the subpixels are "RgbrgB". You can see that there are 4 off subpixels between the red and blue regions, showing a visible wider-than-pixel black gap.
To "fix" this we need to go as far as doing subpixel rendering of all the graphics. Nothing impossible, but low prio and not on the horizon right now. (the correct rendering will offset all the graphics by 1/3 pixel and render again, for each color component...)
The fact that you use CRT doesn't make much difference. I know because I have photographed CRTs recently too, and the subpixel structure of all modern (say, last fifteen years) CRTs is the same as modern LCDs.
Hope that helps.
Hi, as far as I tested this problem happens only with blue & red. Really is not a problem, cairo is great anyway. Thanks for yours attention. marco Sure, only happens with red and blue because those are on the sides of the subpixel. Green is in the middle so doesn't have as much problem. Green is also more luminous than both of red and blue to the eye. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.