From bugzilla-daemon at freedesktop.org Fri Dec 2 17:01:40 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 02 Dec 2016 17:01:40 +0000 Subject: [cairo-bugs] [Bug 98883] BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=98883 --- Comment #3 from Uli Schlachter --- Correct me if I'm wrong, but XLockDisplay() says that there is no other thread that could "steal the next request", right? Also, feel free to correct me, but cairo should be calling XLockDisplay() before doing "SHM stuff". -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Wed Dec 7 17:09:35 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 07 Dec 2016 17:09:35 +0000 Subject: [cairo-bugs] [Bug 98883] BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=98883 --- Comment #4 from Bill Spitzak --- XLockDisplay only works if XInitThreads was done, and that his highly not recommended as it slows Xlib down enormously (because it was very badly implemented with fine-grained locking). -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Wed Dec 7 23:52:04 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 07 Dec 2016 23:52:04 +0000 Subject: [cairo-bugs] [Bug 98883] BadAccess errors in ShmAttach due to thread races with XNextRequest() usage in cairo-xlib-surface-shm.c In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=98883 --- Comment #5 from Karl Tomlinson --- XLockDisplay() would work, and there is no bug if there is only one thread (i.e. when XInitThreads() is not called), but XLockDisplay() is not necessary. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 8 05:14:47 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 08 Dec 2016 05:14:47 +0000 Subject: [cairo-bugs] [Bug 99021] New: bad rendering showing text with CAIRO_ANTIALIAS_BEST Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99021 Bug ID: 99021 Summary: bad rendering showing text with CAIRO_ANTIALIAS_BEST Product: cairo Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: image backend Assignee: chris at chris-wilson.co.uk Reporter: jason at aquaticape.us QA Contact: cairo-bugs at cairographics.org Created attachment 128375 --> https://bugs.freedesktop.org/attachment.cgi?id=128375&action=edit image of bad text rendering Setting the antialias font option to CAIRO_ANTIALIAS_BEST makes text rendering bad, as shown in the following program. cairo_surface_t *surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 80, 40); cairo_t *cr = cairo_create (surface); cairo_move_to (cr, 5, 30); cairo_set_font_size (cr, 30); cairo_font_options_t *font_options = cairo_font_options_create (); cairo_font_options_set_antialias (font_options, CAIRO_ANTIALIAS_BEST); cairo_set_font_options (cr, font_options); cairo_show_text (cr, "hello"); cairo_surface_write_to_png (surface, "out.png"); -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 8 05:44:53 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 08 Dec 2016 05:44:53 +0000 Subject: [cairo-bugs] [Bug 99022] New: Font display issue with Edwardian Script ITC font Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99022 Bug ID: 99022 Summary: Font display issue with Edwardian Script ITC font Product: cairo Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: freetype font backend Assignee: david at freetype.org Reporter: Fahad.alsaidi at gmail.com QA Contact: cairo-bugs at cairographics.org I am trying to solve a bug in scribus[1] with Edwardian Script ITC font. The H letter is never drawn completely. In scribus we draw glyhp by glyph using cairo_show_glyphs[2]. Thinking the problem with our implementation, I test it with HarfBuzz tutorial code [3]. I notice if cairo draws one glyph each time the problem appears but if it draws more than one the problem doesn't appears. I appreciate your help. =============== [1] https://bugs.scribus.net/view.php?id=14324 [2] https://github.com/scribusproject/scribus/blob/c47ee4fc64df91688e0910035d58333801f7a738/scribus/text/screenpainter.cpp#L47 [3] https://github.com/behdad/harfbuzz-tutorial -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 8 07:23:32 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 08 Dec 2016 07:23:32 +0000 Subject: [cairo-bugs] [Bug 99021] bad rendering showing text with CAIRO_ANTIALIAS_BEST In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99021 Lionel Elie Mamane changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lionel at mamane.lu -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 10 17:27:21 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 10 Dec 2016 17:27:21 +0000 Subject: [cairo-bugs] [Bug 99021] bad rendering showing text with CAIRO_ANTIALIAS_BEST In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99021 --- Comment #1 from Uli Schlachter --- I can reproduce the problem. I took a quick look at this has "something" to do with _render_glyph_outline() in src/cairo-ft-font.c. Ignoring the actual passed-in value here and forcing something else is enough to trigger this problem or make it go away. So either this is a bug in freetype or _fill_xrender_bitmap in the same source file mis-converts something here. I don't know and I can't figure out more right now. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sun Dec 11 12:06:31 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sun, 11 Dec 2016 12:06:31 +0000 Subject: [cairo-bugs] [Bug 99054] New: cairo snapshot 1.15.[2, 4], win32 backend: assertion (surface->is_clear) failed Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99054 Bug ID: 99054 Summary: cairo snapshot 1.15.[2,4], win32 backend: assertion (surface->is_clear) failed Product: cairo Version: unspecified Hardware: Other OS: All Status: NEW Severity: critical Priority: medium Component: win32 backend Assignee: cairo-bugs at cairographics.org Reporter: wippbox at gmx.net QA Contact: cairo-bugs at cairographics.org Created attachment 128411 --> https://bugs.freedesktop.org/attachment.cgi?id=128411&action=edit Fix I cross-compiled cairo-1.15.2 and cairo-1.15.4 for windows. When running a test program, I get the following: > Assertion failed! > > File: src/cairo-surface.c, Line 545 > > Expression: surface->is_clear > > abnormal program termination This happens in cairo_surface_create_similar. Adding a line > new_surf->is_clear = TRUE; at the end of _cairo_win32_display_surface_create_similar in src/win32/cairo-win32-display-surface.c fixes the issue (see patch). Remark: The particular case occured only for width = 0 in cairo_surface_create_similar. For width > 0 the issue did not happen. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sun Dec 11 12:07:25 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sun, 11 Dec 2016 12:07:25 +0000 Subject: [cairo-bugs] [Bug 99054] cairo snapshot 1.15.[2, 4], win32 backend: assertion (surface->is_clear) failed In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99054 Gerhard Bräunlich changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 15 11:39:03 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 15 Dec 2016 11:39:03 +0000 Subject: [cairo-bugs] [Bug 99094] New: docs: cairo_surface_create_similar_image accepts dimensions in pixels, not device-space units Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99094 Bug ID: 99094 Summary: docs: cairo_surface_create_similar_image accepts dimensions in pixels, not device-space units Product: cairo Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: general Assignee: chris at chris-wilson.co.uk Reporter: rishi.is at lostca.se QA Contact: cairo-bugs at cairographics.org The cairo_surface_create_similar_image documentation says that the width and height are in device-space units. Instead they are in raw pixels. Basically the same unit used by cairo_image_surface_get_height, cairo_image_surface_get_width, etc.. It might also be nice to mention that cairo_surface_create_similar_image doesn't inherit the device scale, but cairo_surface_create_similar does. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 15 11:42:26 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 15 Dec 2016 11:42:26 +0000 Subject: [cairo-bugs] [Bug 99094] docs: cairo_surface_create_similar_image accepts dimensions in pixels, not device-space units In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99094 --- Comment #1 from Debarshi Ray --- Created attachment 128482 --> https://bugs.freedesktop.org/attachment.cgi?id=128482&action=edit doc: Fix the units used by cairo_surface_create_similar_image -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 15 11:50:41 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 15 Dec 2016 11:50:41 +0000 Subject: [cairo-bugs] [Bug 99094] docs: cairo_surface_create_similar_image accepts dimensions in pixels, not device-space units In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99094 --- Comment #2 from Debarshi Ray --- Created attachment 128483 --> https://bugs.freedesktop.org/attachment.cgi?id=128483&action=edit doc: Clarify when the device scale is inherited and when it isn't -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Thu Dec 15 18:57:12 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 15 Dec 2016 18:57:12 +0000 Subject: [cairo-bugs] [Bug 84952] [PATCH] Recording surface ink extents: difference between two fixed point numbers may overflow before conversion to double In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84952 --- Comment #3 from Carlos Antunes --- It's amazing that, after more than two years, this trivial to fix bug is still present in the code! -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Tue Dec 20 14:50:13 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Tue, 20 Dec 2016 14:50:13 +0000 Subject: [cairo-bugs] [Bug 91271] Conditional jump or move depends on uninitialised value(s) in composite_traps() In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=91271 Michael Catanzaro changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mcatanzaro at gnome.org --- Comment #2 from Michael Catanzaro --- (In reply to Massimo from comment #1) > it happens when in 'composite_traps' traps->num_traps == 0 > > in that case returning CAIRO_STATUS_SUCCESS at line 1829 > > http://cgit.freedesktop.org/cairo/tree/src/cairo-xlib-render-compositor. > c#n1829 > > silences valgrind. So, is that the right thing to do? -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Fri Dec 30 22:41:58 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 30 Dec 2016 22:41:58 +0000 Subject: [cairo-bugs] [Bug 99233] New: Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 Bug ID: 99233 Summary: Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level Product: cairo Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: xlib backend Assignee: chris at chris-wilson.co.uk Reporter: dboles.src at gmail.com QA Contact: cairo-bugs at cairographics.org This was originally reported against GTK+ here: https://bugzilla.gnome.org/show_bug.cgi?id=774270 A primary developer for rendering on GTK+ believes this to be an issue in Cairo or the X driver. So I'm moving it here. I hope there's enough info to do something useful. Unfortunately my knowledge of the tech involved is pretty minimal at this point, but I'll try any tests you want! Basically, by nesting GtkFrames that had identical RGBA components in their background colours and 0 < alpha < 1, I found that child widgets of the innermost frame would not properly draw its background colour as they should. Rather, they would intermittently draw the background colour of an earlier/uppermost frame... although this would flicker to/from the correct colour through such actions as hovering over the widget or resizing the window. By noticing some inconsistencies in when this occurred, I came to realise that by ensuring each successively nested frame's background colour differs from its parent's by at least 1 point (on a 0~255 scale) in at least 1 of the RGB components, then this problem can be worked around. However, if 1 or more of the nested frames' bg colours are the same, things start glitching out. Running the test case with GDK_RENDERING=image to achieve the following... > Always create image surfaces. This essentially turns off all hardware acceleration inside GTK. ...also bypasses the issue. I've tried to run this in Xvfb in an attempt to narrow down whether it's Cairo or X but haven't gotten anywhere fast yet. Again, let me know anything I can do to help diagnose (or redirect) this. Thanks! -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 01:24:45 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 01:24:45 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #1 from Daniel Boles --- I should also note that working around this by bumping RGB values is broken in cases where that's not possible, e.g. where (as in GTK+) you want to use a named colour (e.g. currentColor). It's not possible to extract the RGB parts of that, alter 1, and integrate them back. So we lose functionality in such cases, rather than being a pure workaround. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 10:49:59 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 10:49:59 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #2 from Uli Schlachter --- I can reproduce the problem: * It DOES happen with CAIRO_DEBUG="xrender-version=0.1". * It does NOT happen with CAIRO_DEBUG="xrender-version=0.0" in the env. * It also does NOT occur in Xephyr. Thus, the problem is somewhere in the X11 server / video driver. Besides that, no idea what to do. The bug is assigned to Chris, so let's wait for his wisdom. :-) -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 11:03:44 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 11:03:44 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #3 from Chris Wilson --- Both Cairo and X likely optimise for this case. Uli, simple reproducer for the lazy? -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:30:40 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:30:40 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #4 from Uli Schlachter --- > Uli, simple reproducer for the lazy? Sorry, no. Just drawing smaller-and-smaller rectangles with color (0, 0, 0, 0.2) does not reproduce this issue. GTK must be doing more than just that and I'm not prepared to dick into GTK's rendering loop. Also, the GTK test case "flickers" here, meaning that sometimes I get the expected content and sometimes the wrong one. So why does GTK redrawing this thing when I hover over it with the mouse and what is it doing different in this case? -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:36:06 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:36:06 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #5 from Uli Schlachter --- Created attachment 128696 --> https://bugs.freedesktop.org/attachment.cgi?id=128696&action=edit Simpler, GTK-free test case Whoops. I was wrong. I tested cairo-xcb. At least I know that cairo-xcb is not affected. ;-) Affected program reproduces the issue here. Setting CAIRO_DEBUG="xrender-version=-1.-1" still fixes things. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:41:44 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:41:44 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 Daniel Boles changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dboles.src at gmail.com Attachment #128696|text/x-csrc |text/plain mime type| | -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:42:15 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:42:15 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #6 from Uli Schlachter --- I took a brief look with xtrace: Cairo "compresses" all the rectangles into a single FillRectangles request (first one draws the white background, second one 'the rest') 000:<:001c: 24: RENDER-Request(139,4): CreatePicture pid=0x02800005 drawable=0x02800001 format=0x0000002a values={poly-mode=Imprecise(0x01)} 000:<:001d: 28: RENDER-Request(139,26): FillRectangles op=Src(0x01) dst=0x02800005 red=0xffff green=0xffff blue=0xffff alpha=0xffff rects={x=0 y=0 w=100 h=100}; 000:<:001e: 52: RENDER-Request(139,26): FillRectangles op=Over(0x03) dst=0x02800005 red=0x0000 green=0x0000 blue=0x0000 alpha=0x3333 rects={x=10 y=10 w=80 h=80},{x=20 y=20 w=60 h=60},{x=30 y=30 w=40 h=40},{x=40 y=40 w=20 h=20}; 000:>:001e: Event KeyPress(2) keycode=0x18 time=0x011b6157 root=0x00000117 event=0x02800001 child=None(0x00000000) root-x=967 root-y=785 event-x=966 event-y=744 state=Mod2 same-screen=true(0x01) Since this does not happen in Xephyr, something in the X server is mis-optimising this case, I guess. @Chris: Now is your turn. I always fail to find the broken things in Xorg. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:43:13 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:43:13 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #7 from Daniel Boles --- Thanks both for the thoughts! Let me know if I (and my limited knowledge) can help with anything. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 13:51:22 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 13:51:22 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #8 from Chris Wilson --- Concentric set of XRenderFillRectangles with over and alpha < 1 should produce a gradient of light (outside) to dark (centre). libxrender compresses multiple calls of XRenderFillRectangle with the same op + colour to a single call. X is supposed to render each rectangle in that array as a seperate draw call (though we do try to optimise the computation of the union and use the union if possible by op). Uli, what's the bad rendering? Daniel can you look at Uli's test and see if it has a similar misrendering on your system? -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:04:49 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:04:49 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong colours to be drawn at innermost level In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #9 from Daniel Boles --- (In reply to Chris Wilson from comment #8) > Daniel can you look at Uli's test and see if it has a similar misrendering > on your system? Sure, I just get a single light grey rectangle when running that test. (As Uli noted, the flickering/etc seems to be peculiar to the GTK+ case.) -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:08:05 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:08:05 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 Daniel Boles changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Nesting backgrounds with |Nesting backgrounds with |identical RGBA causes wrong |identical RGBA causes wrong |colours to be drawn at |or missing colours at inner |innermost level |levels -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:10:29 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:10:29 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #10 from Daniel Boles --- Created attachment 128697 --> https://bugs.freedesktop.org/attachment.cgi?id=128697&action=edit Screenshot of Uli's test case -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:11:00 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:11:00 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #11 from Chris Wilson --- The two possible incorrect optimisations: - reducing the array of rectangles to its region - replacing the over with a precomputed SRC (since it assumed no overlap between rectangles) and the surface is a known solid color. Both of those are ddx issues. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:11:36 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:11:36 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #12 from Chris Wilson --- (Not that list is meant to be exhaustative, just personal experience :( -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 14:30:12 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 14:30:12 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #13 from Chris Wilson --- At a guess you are using modesetting/glamor since it exhibits this bug, and the flickering may be a side-effect of another bug in that code in how it misapplies damage. -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla-daemon at freedesktop.org Sat Dec 31 21:28:37 2016 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 31 Dec 2016 21:28:37 +0000 Subject: [cairo-bugs] [Bug 99233] Nesting backgrounds with identical RGBA causes wrong or missing colours at inner levels In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=99233 --- Comment #14 from Daniel Boles --- Does being a DDX issue mean it needs to be reported elsewhere? If so, would you mind doing that, since I'm guessing you have experience and clearly can explain the situation better than me. :D If you'd like me to run any commands to provide info about my graphics hardware and settings, let me know. I can't remember any useful ones at the moment! -- You are receiving this mail because: You are the QA Contact for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: