Bug 4945 (Tiffany)

Summary: Cairo doesn't support 8-bit pseudocolor visuals
Product: cairo Reporter: Nate Byrnes <nate.byrnes>
Component: generalAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: critical    
Priority: high CC: anirkko, arbab, ariggs, ashishyadav26, bofh42, borisv, brian.cameron, bugs, cavergines, chris.wang, claude.bonnard, cpalmer, dave, david.meleedy, dmcmahill, don.lawrence, dumitru.sipos, edgar.hoch, eth0, fboiteux, govindarao, hba, jes, joevandyk, jsarlo, kurt, langel, marek.rouchal, mboguski, pesco, philip.groves, pwalsall, rajkumar.david, robert.buick, R.Vickers, sebastien, steve, tcs27, thayes77, tim.w.connors, tk, tom.nelson, ubieto, wcwince, zaphodb, zds
Version: 1.0.2Keywords: patch
Hardware: All   
OS: All   
Whiteboard:
i915 platform: ALL i915 features:
Bug Depends on:    
Bug Blocks: 5846, 19528    
Attachments: Simple program to demonstrate bug
fix for the 8bit issue + 16 bit.
update of Eric Faurot's patch for 1.2.4
Fix of patch #6762 for true color (for cairo-1.2.4)
updated patch for cairo 1.4.6
Revise the patch to support 8bit truecolor also
screenshot of firefox on 256 color (depth 8) display
Patch which worked on AIX 52
Capture of part of my screen, with 'gkrellm' from new Cairo on the top and from an old no-Cairo version on the bottom
screen capture of Firefox 2.0.0.17 with cairo-1.8.6 on 256 color X11 on Solaris 10 x86
attachment-1164-0.html
attachment-10479-0.html

Description Nate Byrnes 2005-11-02 04:42:21 UTC
When trying to run any gtk app (so it seems, due to the pangocairo, cairo
dependency) on my Tektronix Xterm, the app crashes as the window attempts to
map. This does not happen on Linux-Linux remote X11 (DISPLAY=host:0.0), just
Linux-Xterm (DISPLAY=xterm:0.0). Below is the stacktrace of running gcalctool,
but every other GTK app I run dies the same way. I first discovered this after
upgrading to dropline-gnome 2.12 and tried to login to the xterm via GDM.


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226455360 (LWP 17605)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb75b435d in fbFetch (pict=0x81faaf8, x=0, y=0, width=10, buffer=0xbfd4fc08)
    at fbcompose.c:2673
#2  0xb75b65b3 in fbCompositeRect (data=0xbfd4fbc0, scanline_buffer=0xbfd4fbe0)
    at fbcompose.c:3565
#3  0xb75b6ba6 in pixman_compositeGeneral (op=PIXMAN_OPERATOR_OVER, 
    pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0, 
    yMask=0, xDst=0, yDst=0, width=10, height=64480) at fbcompose.c:3677
#4  0xb75a7022 in *_cairo_pixman_composite (op=PIXMAN_OPERATOR_OVER, 
    pSrc=0x81fabe0, pMask=0x81fa8d8, pDst=0x81faaf8, xSrc=10, ySrc=9, xMask=0, 
    yMask=0, xDst=0, yDst=0, width=10, height=10) at fbpict.c:1825
#5  0xb758c0d3 in _cairo_image_surface_composite (operator=CAIRO_OPERATOR_OVER, 
    src_pattern=0xbfd56210, mask_pattern=0xbfd55eb0, abstract_dst=0x81fab70, 
    src_x=10, src_y=9, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=10, height=10)
    at cairo-image-surface.c:605
#6  0xb75919ef in _fallback_composite (operator=CAIRO_OPERATOR_OVER, 
    src=0xbfd56210, mask=0xbfd55eb0, dst=0x81f9c48, src_x=10, src_y=9, mask_x=0, 
    mask_y=0, dst_x=0, dst_y=0, width=10, height=10) at cairo-surface.c:800
#7  0xb759b091 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x814ecf0, 
    operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48, 
    source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10, 
    glyphs=0x81f9af0, num_glyphs=1) at cairo-ft-font.c:2047
#8  0xb75872dc in _cairo_scaled_font_show_glyphs (scaled_font=0x814ecf0, 
    operator=CAIRO_OPERATOR_OVER, pattern=0xbfd56210, surface=0x81f9c48, 
    source_x=10, source_y=9, dest_x=10, dest_y=9, width=10, height=10, 
    glyphs=0x81f9af0, num_glyphs=1) at cairo-font.c:940
#9  0xb758a8f2 in _cairo_gstate_show_glyphs_draw_func (closure=0xbfd561f0, 
    operator=CAIRO_OPERATOR_OVER, src=0xbfd56210, dst=0x81f9c48, dst_x=0, 
    dst_y=0, extents=0xbfd561e8) at cairo-gstate.c:2053
#10 0xb75893cc in _cairo_gstate_clip_and_composite (clip=0x81fa694, 
    operator=CAIRO_OPERATOR_OVER, src=0xbfd56210, 
    draw_func=0xb758a830 <_cairo_gstate_show_glyphs_draw_func>, 
    draw_closure=0xbfd561f0, dst=0x81f9c48, extents=0xbfd561e8)
    at cairo-gstate.c:1094
#11 0xb758ab0e in _cairo_gstate_show_glyphs (gstate=0x81fa610, 
    glyphs=0xbfd562f0, num_glyphs=1) at cairo-gstate.c:2131
#12 0xb75840ec in cairo_show_glyphs (cr=0x81f9ab8, glyphs=0x0, 
    num_glyphs=136292848) at cairo.c:2158
#13 0xb75bf2bd in pango_cairo_renderer_draw_glyphs (renderer=0x81fa450, 
    font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pangocairo-render.c:110
#14 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81fa450, 
    font=0x8146b70, glyphs=0x81606e8, x=0, y=0) at pango-renderer.c:597
#15 0xb75bf7f4 in pango_cairo_show_glyph_string (cr=0x81f9ab8, font=0x8146b70, 
    glyphs=0x81606e8) at pangocairo-render.c:314
#16 0xb7ae5df9 in gdk_pango_context_get_for_screen ()
   from /usr/lib/libgdk-x11-2.0.so.0
#17 0x081f9ab8 in ?? ()
#18 0x08146b70 in ?? ()
#19 0x081606e8 in ?? ()
#20 0x00000000 in ?? ()
#21 0x40330000 in ?? ()
#22 0xb74720d2 in ?? () from /usr/lib/libpango-1.0.so.0
#23 0xbfd56710 in ?? ()
#24 0xbfd56700 in ?? ()
#25 0xb746ef38 in ?? () from /usr/lib/libpango-1.0.so.0
#26 0xb757ba58 in ?? ()
#27 0x081672f8 in ?? ()
#28 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#29 0x00000000 in ?? ()
#30 0x081f9e70 in ?? ()
#31 0xbfd56718 in ?? ()
#32 0x081f9ab8 in ?? ()
#33 0x00000014 in ?? ()
#34 0x00000003 in ?? ()
#35 0x00000000 in ?? ()
#36 0xb7a66794 in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 
#37 0xb7ac9f00 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#38 0xb7b533a8 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#39 0xb7f5bfd8 in ?? () from /lib/ld-linux.so.2
#40 0x00000001 in ?? ()
#41 0xb757ba58 in ?? ()
#42 0x00000001 in ?? ()
#43 0x08163638 in ?? ()
#44 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#45 0x081f9e70 in ?? ()
#46 0x081f9e70 in ?? ()
#47 0xbfd56738 in ?? ()
#48 0xb74a2fb0 in ?? () from /usr/lib/libpango-1.0.so.0
#49 0x081f9e70 in ?? ()
#50 0x081f9e70 in ?? ()
#51 0xbfd56758 in ?? ()
#52 0xb748ba18 in pango_renderer_draw_glyphs (renderer=0x81606e8, 
    font=0x8128b68, glyphs=0x811ff68, x=135520048, y=0) at pango-renderer.c:597
Comment 1 Bob 2005-11-04 06:29:28 UTC
I am seeing someting very similar on NCD and IBM X terminals. On SuSE 10.0
firefox 1.0.7 crashes with a segmentation fault as soon as you start it. I have
gtk2-2.8.3-4
cairo-1.0.0-7.2

Here is my traceback:

#0  0x00000000 in ?? ()
#1  0xb3658842 in _cairo_pixman_composite_tri_fan ()
   from /usr/lib/libcairo.so.2
#2  0xb365b906 in _cairo_pixman_composite_tri_fan ()
   from /usr/lib/libcairo.so.2
#3  0xb364bc69 in _cairo_pixman_region_intersect () from /usr/lib/libcairo.so.2
#4  0xb362d4a9 in cairo_image_surface_get_height () from /usr/lib/libcairo.so.2
#5  0xb3632d89 in cairo_surface_create_similar () from /usr/lib/libcairo.so.2
#6  0xb362a573 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#7  0xb3629cb6 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#8  0xb362a97b in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#9  0xb362ab87 in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#10 0xb362ac6a in cairo_font_options_get_hint_metrics ()
   from /usr/lib/libcairo.so.2
#11 0xb3624609 in cairo_stroke_preserve () from /usr/lib/libcairo.so.2
#12 0xb3624632 in cairo_stroke () from /usr/lib/libcairo.so.2
#13 0xb38e656e in gtk_style_apply_default_background ()
   from /opt/gnome/lib/libgtk-x11-2.0.so.0
#14 0xb38ed0c0 in gtk_paint_check () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#15 0x081c1aca in nsCharPtrHashKey::nsCharPtrHashKey ()
#16 0x081c0768 in nsCharPtrHashKey::nsCharPtrHashKey ()
#17 0x0823d4ff in nsCOMTypeInfo<nsITimerInternal>::GetIID ()
#18 0x0823df08 in nsCOMTypeInfo<nsITimerInternal>::GetIID ()
#19 0x08204c63 in nsIBidirectionalEnumerator::nsIBidirectionalEnumerator ()
#20 0x0825b55d in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#21 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#22 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#23 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#24 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#25 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#26 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#27 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#28 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#29 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#30 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#31 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#32 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#33 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#34 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#35 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#36 0x0825e0c3 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#37 0x0825c352 in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#38 0x0825b5ea in nsCOMTypeInfo<nsISupportsPRInt32>::GetIID ()
#39 0x083e37bc in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#40 0x083e2e42 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#41 0x083e2624 in nsCOMPtr<nsIObjectInputStream>::nsCOMPtr ()
#42 0x08215570 in nsCOMPtr<nsIBidirectionalEnumerator>::nsCOMPtr ()
#43 0x08368f61 in nsCOMTypeInfo<nsICollection>::GetIID ()
#44 0x0836b89e in nsCOMTypeInfo<nsICollection>::GetIID ()
#45 0x0836eedf in nsCOMTypeInfo<nsICollection>::GetIID ()
#46 0x0836f8b5 in nsCOMTypeInfo<nsICollection>::GetIID ()
#47 0x0836fc5f in nsCOMTypeInfo<nsICollection>::GetIID ()
#48 0x08369002 in nsCOMTypeInfo<nsICollection>::GetIID ()
#49 0x081fe29b in nsCOMPtr<nsISupports>::nsCOMPtr ()
#50 0x081fa4a8 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#51 0x081fa4e3 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#52 0xb388ae60 in gtk_marshal_VOID__UINT_STRING ()
   from /opt/gnome/lib/libgtk-x11-2.0.so.0
#53 0xb35ebd19 in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0
#54 0xb35fb816 in g_signal_stop_emission ()
   from /opt/gnome/lib/libgobject-2.0.so.0
#55 0xb35fcbee in g_signal_emit_valist ()
   from /opt/gnome/lib/libgobject-2.0.so.0
#56 0xb35fd1f5 in g_signal_emit () from /opt/gnome/lib/libgobject-2.0.so.0
#57 0xb397d3b4 in gtk_widget_activate ()
   from /opt/gnome/lib/libgtk-x11-2.0.so.0
#58 0xb3889845 in gtk_main_do_event () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#59 0xb37073fd in gdk_window_clear_area_e ()
   from /opt/gnome/lib/libgdk-x11-2.0.so.0
#60 0xb37074df in gdk_window_process_all_updates ()
   from /opt/gnome/lib/libgdk-x11-2.0.so.0
#61 0xb3707565 in gdk_window_process_all_updates ()
   from /opt/gnome/lib/libgdk-x11-2.0.so.0
#62 0xb3581941 in g_child_watch_add () from /opt/gnome/lib/libglib-2.0.so.0
#63 0xb357f35c in g_main_context_dispatch ()
   from /opt/gnome/lib/libglib-2.0.so.0
#64 0xb35827cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0
#65 0xb3582ce7 in g_main_context_iteration ()
   from /opt/gnome/lib/libglib-2.0.so.0
#66 0x081fdae0 in nsCOMPtr<nsISupports>::nsCOMPtr ()
#67 0x0857d697 in nsCOMPtr<nsIEventQueue>::nsCOMPtr ()
#68 0x084d2411 in nsCOMTypeInfo<nsIProcess>::GetIID ()
#69 0x084d114b in nsCOMTypeInfo<nsIProcess>::GetIID ()
#70 0x086edd56 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID ()
#71 0x086ef526 in nsCOMTypeInfo<nsIBinaryInputStream>::GetIID ()
#72 0x080810db in ?? ()
#73 0x00000001 in ?? ()
#74 0xbfd446a4 in ?? ()
#75 0x086f88d0 in _IO_stdin_used ()
#76 0xbfd44678 in ?? ()
#77 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6
#78 0xb2f44ea0 in __libc_start_main () from /lib/tls/libc.so.6
#79 0x08081031 in ?? ()

Hope this can be fixed, it is a complete showstopper for SuSE 10 at this site.

Bob
Comment 2 Bob 2005-11-04 08:11:01 UTC
More news on this: a colleague reports that if you reconfigure the terminal to
use 16-bit colour instead of 8-bit then the problem goes away.

However this is an unhelpful solution for us: we switched the terminals to 8-bit
because firefox frequently crashed when visiting graphics-intensive sites.

Bob
Comment 3 Carl Worth 2005-11-04 09:11:36 UTC
I've updated the summary to note the limitation of this bug to the cased of X
servers running in 8-bit pseudocolor mode.
Comment 4 Nate Byrnes 2005-11-05 07:50:31 UTC
Regarding the recommendation to switch to 16-bit color... I cannot. The
tektronix is 8-bit only, as are many of the older X-Term products I have used
(NCD, IBM-Netstation). I really would love to go 16-bit if I could.
Comment 5 Dom Lachowicz 2006-01-06 14:34:46 UTC
*** Bug 5196 has been marked as a duplicate of this bug. ***
Comment 6 David Hembrow 2006-02-02 06:58:01 UTC
I believe I'm seeing the same problem. I have a Tektronix XP117C X terminal,
which is 8 bit only, so changing the configuration to 16 bit or more is not
possible. I'm using GTK 2.8.6-0ubuntu2.1.

All sorts of old style X apps work fine if started on the display (i.e. xterm,
xeyes, xclock etc.), but gdm and such like don't work.

If this problem gets fixed, I'd be very pleased to hear about it.

David.
Comment 7 Bob 2006-03-10 01:03:30 UTC
I can imagine this bug could well be problematic for the developers because they
may not have access to old equipment. Is there anything those of us with 8-bit X
terminals can do to speed things up? It would cost this department about $25000
to replace all our 8-bit terminals, so I'm willing to invest some effort in
providing good debugging information, or testing out new versions of software. 
Comment 8 Bob 2006-03-10 02:35:02 UTC
Created attachment 4872 [details]
Simple program to demonstrate bug

I downloaded a very simple Cairo demo from the Gnome Journal and this also
triggers the bug. The attachment includes:
(1) program source
(2) Makefile
(3) Debugging traceback (in cairo.log)

To compile the program type
  make clock3
Comment 9 Bob 2006-03-15 03:02:33 UTC
More information: this bug is a close relation of
https://bugs.freedesktop.org/show_bug.cgi?id=5846
and possibly the same. A colleague of mine built libcairo with the workround
suggested there and found that firefox and other applications now ran without
crashing on 8-bit terminals. However, there were some issues with text
displaying strangely, so there is still work to be done. 

Bob
Comment 10 Owen Taylor 2006-03-15 03:10:17 UTC
Retitling to hopefully make it clear that this isn't some problem
that needs diagnosis. If someone is interested in doing the work
(probably a week or so's worth of work), that could be discussed on
the cairo mailing list. Of course, making it stop crashing is easier
than making but of pretty limited value...


Comment 11 Carl Worth 2006-03-25 09:03:06 UTC
*** Bug 6379 has been marked as a duplicate of this bug. ***
Comment 12 Johan Boulé 2006-04-07 04:00:58 UTC
(In reply to comment #7)
> I can imagine this bug could well be problematic for the developers because they
> may not have access to old equipment.

couldn't we argue that cairo and gtk/gdk/pango developers could have at least
tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest?
Comment 13 Carl Worth 2006-04-07 04:28:00 UTC
(In reply to comment #12)
> couldn't we argue that cairo and gtk/gdk/pango developers could have at least
> tested 8-bit pseudo color and bgr/rgb true-color visuals on Xvnc or Xnest?

Certainly, getting access to an X server with an 8-bit pseudo-color visual is
not the problem. So, you're correct that an offer of hardware won't help get the
problem fixed.

The reason this situation exists is not due to some careless lack of testing.
For cairo at least, there was a conscious acknowledgment from the developers
that have been working on cairo so far that the 8-bit pseudo-color case is
uninteresting.

Obviously, (from the traffic here), there are users that are interested in this
case. So what falls to the users is finding a capable developer that is
motivated (or that could be made motivated) to fix this.
Comment 14 Carl Worth 2006-04-19 17:07:26 UTC
*** Bug 5205 has been marked as a duplicate of this bug. ***
Comment 15 Bob 2006-04-21 23:23:05 UTC
(In reply to comment #13)
> 
> The reason this situation exists is not due to some careless lack of testing.
> For cairo at least, there was a conscious acknowledgment from the developers
> that have been working on cairo so far that the 8-bit pseudo-color case is
> uninteresting.
> 

Sadly there is a bit of a clash of expectations here. The Cairo developers are
busy working on what they find interesting, while in another part of the free
software ecosystem distributors like SuSE are including this partially
functional software in their products and selling it to the general public.
Comment 16 Carl Worth 2006-04-22 02:44:28 UTC
(In reply to comment #15)
>
> Sadly there is a bit of a clash of expectations here. The Cairo developers are
> busy working on what they find interesting, while in another part of the free
> software ecosystem distributors like SuSE are including this partially
> functional software in their products and selling it to the general public.

If a software distributor wants to sell you a product that doesn't meet your
needs, then don't buy it. There really are connections between what paying
customers care about and what developers will find interesting to work on.
Comment 17 Eric Faurot 2006-04-27 00:25:31 UTC
(In reply to comment #16)

(well, not really)

Hi,

I add this note to the tracker (after a suggestion by Bob) to let people not
following the cairo devel list know that I have written a patch for that isue:

http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c

I have personally tested it on OpenBSD/macppc in various combinations of
ati/wscons drivers and ssh-X/-Y. I also have postive feedback from Bob
(thank you). If you find this useful let me know, also read
http://ekyo.nerim.net/software/index.html

Eric.
Comment 18 Tom Nelson 2006-05-03 04:16:41 UTC
For what it is worth I've had to workaround cairo color issues as a developer 
of a comercial product built on top of wxwidgets, by using gtk+2.6.10 the last 
gtk version before the adoption of cairo.  My research indicates that QT on top 
of cairo gtk also had similar issues.  To our surprise our first comercial 
customers wanted to use our product on X-Win32 and Solaris and encounted some 
of these issues.  

I very much look forward to the incorporation of this bug fix into a future 
cairo release and suggest that perhaps bugs 5212, 5681, and 5846 may be related.

I have a news group corespondence on gmane.comp.lib.wxwindows.general (search 
for "Apparent RGB") that may be of interest.  Thanks -- Tom
Comment 19 woods-logins-for-bug-reporting-are-stupid-and-counter-productive 2006-05-12 03:45:52 UTC
FYI this bug has now wasted a week's worth of my time in trying to upgrade
packages that previously worked A-OK in my environments on NetBSD (i386, alpha,
and sparc).  Confusion with weird pthread problems on SMP machines, along with
the fact that this bugzilla database doesn't seem to be indexed very well by
google didn't help of course.  :-)

It's now a complete show-stopper for me for any and all applications needing
gtk2+.

gtk-demo is a great canonical example program that crashes on all platforms I've
tested.

Note that prior to these upgrades all the applications I'm attempting to upgrade
worked OK even on monochrome displays (albiet with some invisible features
whenever too many colours are used in proximity with each other by the
application).

Note of course that the bug is still present in 1.0.4 as well.

I'll be testing out the patch suggested in a recent comment.
Comment 20 Eric Faurot 2006-06-03 09:58:27 UTC
Created attachment 5796 [details] [review]
fix for the 8bit issue + 16 bit.

Hi all,

There was a bug in my previous fix. Color channels were mixed up
on some archs. This should be much better now. It should also be faster.
I have also added a workaround for 16bits displays with the RENDER extension
disabled.

Also updated there:
http://ekyo.nerim.net/software/patch-src_cairo-xlib-surface_c

Eric.
Comment 21 Behdad Esfahbod 2006-06-13 22:57:35 UTC
*** Bug 4505 has been marked as a duplicate of this bug. ***
Comment 22 Brian Cameron 2006-07-10 10:38:22 UTC
This patch seems to work against cairo 1.0, not 1.2.  Is there an updated patch
for the new release of cairo, or can this patch be integrated into cairo?
Comment 23 Eric Faurot 2006-07-21 09:10:42 UTC
(In reply to comment #22)
> This patch seems to work against cairo 1.0, not 1.2.  Is there an updated patch
> for the new release of cairo, or can this patch be integrated into cairo?

Hi,

I have just ported my patch to cairo-1.2.0.
http://ekyo.nerim.net/software/patch-1.2.0-src_cairo-xlib-surface_c
Eric.
Comment 24 Carl Worth 2006-08-30 10:56:24 UTC
*** Bug 8073 has been marked as a duplicate of this bug. ***
Comment 25 Dan McMahill 2006-08-30 11:52:49 UTC
any chance of a patch against 1.2.4?  I just checked 1.2.4 and it still has this
problem.  Unfortunately the 1.2.0 patch didn't apply cleanly and I don't
understand it enough to work it into the 1.2.4 code.  Surely this must affect
quite a number of users.  For now I will just not move past gtk-2.6.

Just to append to this, I'm using a Sun ultra/10 with the default graphics card.
 In this case that means I'm running 8-bit psuedocolor.  Thats the best you get
with 1280 x 1024.  To go to something like 24-bit color you have to drop down to
1024 x 768 which is just not enough.  Granted this is not a cutting edge machine
but I'll bet there are a lot of them deployed.  I'd be happy to test out any
patches.
Comment 26 Dan McMahill 2006-08-31 04:58:57 UTC
Created attachment 6762 [details] [review]
update of Eric Faurot's patch for 1.2.4

I managed to get Eric's patch for 1.2.0 to apply to 1.2.4 with some manual
help.  I can't claim to understand his changes (or any of cairo's internals),
but with this patch I can display gtk apps on my sun ultra/10 again.

Are there any plans of integrating this into the main sources?

Thanks
-Dan
Comment 27 Markus Schwarzenberg 2006-09-05 02:31:48 UTC
Created attachment 6819 [details] [review]
Fix of patch #6762 for true color (for cairo-1.2.4)

The patch #6762 works indeed for 8-bit Pseudo-Color with SUN-X-Servers, but
breaks 24-Bit-True Color Visual compatibility there. The new attchment contains
a patch derived from #6762 wich works also with True Color. Additionally, code
parts aparrantly obsoleted (?) by pango-1.2 (WORKAROUND_8BIT_GRAYLEVEL,
WORKAROUND_R5G6B5) have been removed. By now it's tested only briefly with
SUN-X-Server on 8-bit Pseudo-Color and 24-Bit-True Color Visuals.
Comment 28 Carl Worth 2006-09-25 09:53:28 UTC
*** Bug 8416 has been marked as a duplicate of this bug. ***
Comment 29 Dan McMahill 2006-09-30 03:28:13 UTC
This is just a note that attachement #6819 seems to work for me.  I'm using an
8-bit psuedocolor display (Sun ultra/10, solaris-2.9, Xsun).

What are the chances of this patch making its way back to the main sources?

Thanks
-Dan
Comment 30 Chris Palmer 2006-09-30 15:21:17 UTC
I would prefer a patch that has all the workarounds (WORKAROUND_8BIT_GRAYLEVEL and
WORKAROUND_R5G6B5 included) and doesn't break 24-Bit-True Color Visual compatibility. I think the workarounds are useful (or could potentially be useful) for more than just pango. 
Comment 31 Sven Moritz Hallberg 2006-10-22 13:58:03 UTC
I'm experiencing the same "crash-all-gtk-apps" symptom on my remote setup. Of 
note is that the display in question is 16bit, the problem also appears at 
24bit. My segfault, when running 'gtk-demo' happens in 
_cairo_xlib_surface_show_glyphs:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1218046288 (LWP 16941)]
    0xb78f8039 in _cairo_xlib_surface_show_glyphs () from /usr/lib/libcairo.so.2

The client machine is Linux/Intel whereas the X server is running on Linux/
PowerPC.
Comment 32 Sven Moritz Hallberg 2006-10-22 14:03:25 UTC
(In reply to comment #31)
Right, these are Cairo 1.2.4 and GTK 2.10.6...
Comment 33 Behdad Esfahbod 2006-10-25 14:24:50 UTC
*** Bug 8382 has been marked as a duplicate of this bug. ***
Comment 34 Behdad Esfahbod 2006-10-25 14:25:04 UTC
*** Bug 8530 has been marked as a duplicate of this bug. ***
Comment 35 Behdad Esfahbod 2006-10-25 14:25:11 UTC
*** Bug 8764 has been marked as a duplicate of this bug. ***
Comment 36 drahflow 2006-10-31 03:02:08 UTC
Seems like I have a similar problem, only now cairo spills some error messages about not supporting 8-bit visuals.
Comment 37 Florian Heigl 2006-11-20 12:40:11 UTC
Hi,

I also hit this behaviour in a RHEL5 + Sun Secure Global Desktop scenario.

Error: Cairo does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red   mask: 0x00000000
        Blue  mask: 0x00000000
        Green mask: 0x00000000
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
gnome_segv: cairo-image-surface.c:144: _cairo_format_from_pixman_format: Asserti
on `NOT_REACHED' failed.

[root@localhost ~]# rpm -aq | grep -i pango
pango-1.13.4-2
pycairo-1.2.0-1.1
cairo-1.2.0-2

I read through all the related info here now, and I think someone from the dev's
should test the patches submitted here AND drop a line to Redhat. They might
want to patch up their version.

FYI, i think I can switch my colordepth setting somewhere, but when I hit the
error I ended up getting about 200 windows created till I could kill it - *not*
pleasant :))
Comment 38 Behdad Esfahbod 2006-11-21 14:36:28 UTC
*** Bug 9115 has been marked as a duplicate of this bug. ***
Comment 39 Behdad Esfahbod 2006-12-08 09:50:09 UTC
*** Bug 9283 has been marked as a duplicate of this bug. ***
Comment 40 Mikolaj Kucharski 2006-12-23 17:57:18 UTC
On OpenBSD 4.0-current (Wed Dec  6 03:34:00 MST 2006), X.org 6.9.0 depth 16bit
with cairo-1.2.6 gtk+2-2.10.6 pango-1.14.7 and patch id=6819 form this bug
id=4945 nautilus 2.16.3 crashes like:

Breakpoint 1, cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000, 
    bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
    at cairo-xlib-surface.c:2154
2154        return _cairo_xlib_surface_create_internal (dpy, bitmap, screen,
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000, 
    drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0, 
    width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
2065        if (xrender_format == NULL && 
(gdb) bt
#0  0x0919e97d in _cairo_xlib_surface_create_internal (dpy=0x7c24c000, 
    drawable=4194436, screen=0x7d2a8b80, visual=0x0, xrender_format=0x0, 
    width=139, height=78, depth=1) at cairo-xlib-surface.c:2065
#1  0x0919eb15 in cairo_xlib_surface_create_for_bitmap (dpy=0x7c24c000, 
    bitmap=4194436, screen=0x7d2a8b80, width=139, height=78)
    at cairo-xlib-surface.c:2154
#2  0x0adcd87a in gdk_x11_ref_cairo_surface (drawable=0x885f9640)
    at gdkdrawable-x11.c:1474
#3  0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x885f9640)
    at gdkdraw.c:1263
#4  0x0ada9110 in gdk_pixmap_ref_cairo_surface (drawable=0x808914d0)
    at gdkpixmap.c:515
#5  0x0ad9cd7e in _gdk_drawable_ref_cairo_surface (drawable=0x808914d0)
    at gdkdraw.c:1263
#6  0x0ad98a69 in gdk_cairo_create (drawable=0x808914d0) at gdkcairo.c:45
#7  0x0ada350b in get_cairo_context (gdk_renderer=0x884ad010, 
    part=PANGO_RENDER_PART_FOREGROUND) at gdkpango.c:160
#8  0x0ada36c4 in gdk_pango_renderer_draw_glyphs (renderer=0x884ad010, 
    font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416) at gdkpango.c:230
#9  0x021065ef in pango_renderer_draw_glyphs (renderer=0x884ad010, 
    font=0x7d8982d0, glyphs=0x814f75d0, x=3584, y=60416)
    at pango-renderer.c:598
#10 0x021063e8 in pango_renderer_draw_layout_line (renderer=0x884ad010, 
    line=0x80891368, x=3584, y=60416) at pango-renderer.c:529
#11 0x02105c00 in pango_renderer_draw_layout (renderer=0x884ad010, 
    layout=0x89312678, x=1024, y=50176) at pango-renderer.c:183
#12 0x0ada51d3 in gdk_draw_layout_with_colors (drawable=0x808914d0, 
    gc=0x81907dd0, x=1, y=49, layout=0x89312678, foreground=0x0, 
    background=0x0) at gdkpango.c:1029
#13 0x0ada54b3 in gdk_draw_layout (drawable=0x808914d0, gc=0x81907dd0, x=1, 
    y=49, layout=0x89312678) at gdkpango.c:1091
#14 0x1c0cd999 in nautilus_undo_transaction_unregister_object ()
#15 0x1c0cc827 in nautilus_undo_transaction_unregister_object ()
#16 0x1c0cb793 in nautilus_undo_transaction_unregister_object ()
#17 0x1c0b1162 in nautilus_icon_container_request_update_all ()
#18 0x061b6dfe in g_cclosure_marshal_VOID__OBJECT ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#19 0x061a5f6e in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#20 0x061b6081 in g_signal_emit_by_name ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#21 0x061b521e in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#22 0x061b5560 in g_signal_emit_by_name ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#23 0x049eab7a in gtk_drag_begin_internal (widget=0x8885c018, site=0x0, 
    target_list=0x87b135c0, actions=46, button=1, event=0x829d96a8)
    at gtkdnd.c:2262
#24 0x049eaf40 in gtk_drag_begin (widget=0x8885c018, targets=0x87b135c0, 
    actions=46, button=1, event=0x829d96a8) at gtkdnd.c:2378
#25 0x1c0b1348 in nautilus_icon_container_request_update_all ()
#26 0x1c0a7fdf in nautilus_file_is_gone ()
#27 0x0488532e in _gtk_marshal_BOOLEAN__BOXED (closure=0x8a7328d0, 
    return_value=0xcf7e0a50, n_param_values=2, param_values=0xcf7e0bb0, 
    invocation_hint=0xcf7e0a78, marshal_data=0x1c0a7e00) at gtkmarshalers.c:84
#28 0x061a61e6 in g_cclosure_new_swap ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#29 0x061a5f6e in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#30 0x061b5b3b in g_signal_emit_by_name ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#31 0x061b5051 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.1200.4
#32 0x061b548b in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.1200.4
#33 0x049d00f7 in gtk_widget_event_internal (widget=0x8885c018, 
    event=0x829d96a8) at gtkwidget.c:3911
#34 0x049cfc8d in gtk_widget_event (widget=0x8885c018, event=0x829d96a8)
    at gtkwidget.c:3717
#35 0x048839c5 in gtk_propagate_event (widget=0x8885c018, event=0x829d96a8)
    at gtkmain.c:2188
#36 0x048825c4 in gtk_main_do_event (event=0x829d96a8) at gtkmain.c:1422
#37 0x0add15d1 in gdk_event_dispatch (source=0x88f6c040, callback=0, 
    user_data=0x0) at gdkevents-x11.c:2320
Comment 41 Behdad Esfahbod 2007-01-09 21:30:10 UTC
*** Bug 9587 has been marked as a duplicate of this bug. ***
Comment 42 Behdad Esfahbod 2007-03-19 04:52:25 UTC
Patch used in Sun's JDS: http://cvs.opensolaris.org/source/xref/jds/spec-files/trunk/patches/cairo-02-8bit-fix.diff
Comment 43 Behdad Esfahbod 2007-03-31 23:10:53 UTC
*** Bug 10460 has been marked as a duplicate of this bug. ***
Comment 44 Behdad Esfahbod 2007-04-01 10:52:05 UTC
*** Bug 10469 has been marked as a duplicate of this bug. ***
Comment 45 Behdad Esfahbod 2007-04-03 12:49:14 UTC
*** Bug 10516 has been marked as a duplicate of this bug. ***
Comment 46 Behdad Esfahbod 2007-04-05 11:30:53 UTC
*** Bug 10532 has been marked as a duplicate of this bug. ***
Comment 47 Dan McMahill 2007-04-06 13:26:36 UTC
By my count there have been 16 other bug reports marked as duplicates of this one.  Several patches have been offered and unless I missed it, there has been no negative feedback about these patches which has not been addressed.

Is there any chance at all of these patches ever making their way back into the main source tree?  Or is it always going to be the case that users will have to maintain patches if they care about users that may have older displays?  Note that some users may be running on high end computers but still may have older displays and are thus crippled with this.

I'm sure many of us would like to hear some official feedback especially if it is a step towards getting this fixed in the official sources.  It seems there is no shortage of users to test patches although as someone pointed out quite a while back, VNC can give you access to displays with different color depths.

I hate to complain too much because I'm someone who also contributes quite a bit to various open source projects I realize there isn't always time to look at all the bug reports and patch submissions, but at the same time, cairo is really critical to many many apps and it seems that the patches proposed here are seeing quite a bit of real life use and day to day testing.
Comment 48 Chris Palmer 2007-04-06 16:39:19 UTC
Perhaps it is because all the patches I've seen would need some
tidying up before they'd be suitable - `patch' is very much the
right word for the code given within them. They work, but
you wouldn't want cairo to be comprised entirely of these patches.
I would expect that if one of the patches was polished up a bit, it might
have a better chance of being merged...
Comment 49 Carl Worth 2007-04-06 17:39:48 UTC
(In reply to comment #47)
> By my count there have been 16 other bug reports marked as duplicates of this
> one.

Yes, and the duplicates alone are annoying enough that I'd definitely like to see this bug (and other similar ones) go away for good. We've even added this to the RAODMAP for somewhere along the 1.4.x or 1.6. See:

    http://cairographics.org/ROADMAP

> Several patches have been offered and unless I missed it, there has been
> no negative feedback about these patches which has not been addressed.

That's primarily because I've never even seen a patch that the author has suggested was clean or complete.

And I believe the most recent discussion has happened on the cairo mailing list,  not here in bugzilla, (and the whole split-conversation thing is something that I dislike about bugzilla very much).

Here's a pointer to what I think is the most recent post on the mailing list on the topic:

http://lists.freedesktop.org/archives/cairo/2007-February/009731.html

I'd be happy to have help with this, (including success reports),

-Carl
Comment 50 Dan McMahill 2007-04-06 18:19:06 UTC
thanks.  I'll direct further questions to the mailing list.  FWIW, here is a link to the patch currently used by NetBSD pkgsrc:  http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/graphics/cairo/patches/patch-ae

It seems to work alright for me with a Sun ultra/10 display (8 bit psuedo color) and we have not been hearing complaints from other users with more modern displays.  Since cairo affects much of gnome as well as firefox/thunderbird/etc it is reasonably safe to assume that the attached patch has received a fair amount of road testing.
Comment 51 Behdad Esfahbod 2007-04-10 08:34:36 UTC
*** Bug 10588 has been marked as a duplicate of this bug. ***
Comment 52 Brian Cameron 2007-05-03 00:40:13 UTC
Created attachment 9844 [details] [review]
updated patch for cairo 1.4.6


I noticed that the latest version of this patch is for cairo 1.4.2 and apply against cairo 1.4.6.  The code is pretty much the same, though the structures have now moved into cairo-xlib-surface-private.h.

I notice when I log into my session passing "-depth 8" to the Xorg Xserver, so I am running in 8bit mode that there are some problems:

- sometimes the background image doesn't look right.  Depending on the 
  background image used, it looks like it isn't being scaled cleanly or it
  sometimes has horizontal black lines running through the image.
- I also notice that gnome-screenshot seems to take really messed up pictures 
  of the desktop.  

So I'm not sure 8bit mode works perfectly even with this patch applied, though those bugs may not be related to cairo.  I'm not sure.  I see the exact same problems running with the earlier version of the patch with cairo 1.4.0, so I do not think these problems are introduced by my update of the patch.

I haven't filed bugs against these two issues yet since this 8bit logic isn't yet integrated into cairo.  I just mention I am seeing these problems so the cairo developers can look into this and see if they might understand what the problems may be.  If these aren't cairo problems, we probably should file bugs against control-center Desktop Background capplet and gnome-screenshot once this patch goes upstream.
Comment 53 Carl Worth 2007-06-06 15:26:09 UTC
*** Bug 10947 has been marked as a duplicate of this bug. ***
Comment 54 Carl Worth 2007-06-08 16:19:14 UTC
*** Bug 11202 has been marked as a duplicate of this bug. ***
Comment 55 Carl Worth 2007-06-08 17:01:17 UTC
*** Bug 11175 has been marked as a duplicate of this bug. ***
Comment 56 Kalle Vahlman 2007-07-12 05:16:33 UTC
*** Bug 11405 has been marked as a duplicate of this bug. ***
Comment 57 chris wang 2007-08-09 22:16:15 UTC
It seems that cairo not only doesn't support 8bit pseudocolor but also Truecolor, remember there is still a case that the 8bit color represent as truecolor with 2bit blue, 3bit Green and 3bit Red, this kind of color system still been used in some case. 
Comment 58 chris wang 2007-08-09 22:17:10 UTC
Created attachment 11071 [details] [review]
Revise the patch to support 8bit truecolor also
Comment 59 Carl Worth 2007-08-21 17:33:18 UTC
*** Bug 11745 has been marked as a duplicate of this bug. ***
Comment 60 Carl Worth 2007-08-21 17:34:06 UTC
*** Bug 11926 has been marked as a duplicate of this bug. ***
Comment 61 Carl Worth 2007-08-21 17:34:31 UTC
*** Bug 12010 has been marked as a duplicate of this bug. ***
Comment 62 Carl Worth 2007-11-28 12:35:32 UTC
*** Bug 13386 has been marked as a duplicate of this bug. ***
Comment 63 Tiffany Hayes 2007-12-10 13:27:42 UTC
So I'm trying to figure out how to apply this patch. I will say I know almost nothing about Linux, but I am a physics/astrophysics major, and most of our programs are written in Linux. It's been a helluva ride getting my program to run in Linux period, and now part of it requires running in 8 bit. But every time I try to start an 8-bit window, I get the Cairo error. If this patch can let me run my 8-bit, it will be a life saver. can anybody tell me what I do with this patch to make it work?
Comment 64 Carl Worth 2007-12-13 11:17:54 UTC
*** Bug 13642 has been marked as a duplicate of this bug. ***
Comment 65 Marek Rouchal 2008-01-03 05:47:15 UTC
I stumbled across a similar problem: Firefox wouldn't start on a 256-color Citrix Metaframe (aka ICA) display (commercial software to display X on a Windows PC). So I took cairo-1.4.12, applied the most recent of the attached patches, compiled my own libcairo, and started firefox 2.0.0.6 with LD_LIBRARY_PATH set to the new libcairo, which resulted in this error message:

Error: Cairo 1.4.12 does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red   mask: 0x00000000
        Green mask: 0x00000000
        Blue  mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
firefox-bin: cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.

I tried changing line 173 of src/cairo-image-surface.c to:
    case 8:
       if ((am == 0xff || am == 0x0) &&

But that did not help - firefox then crashes with a segfault. Could be that the version jump of libcairo.so.2.9.2 to libcairo.so.2.11.6 was too high, and I'd have to recompile all GTK/firefox, which I cannot afford. I will try patching the older release of cairo (1.2.4), and let you know...
Comment 66 Marek Rouchal 2008-01-04 03:20:52 UTC
(In reply to comment #65)
> I will try patching
> the older release of cairo (1.2.4), and let you know...

I used Dan's patch (https://bugs.freedesktop.org/attachment.cgi?id=6762) on cairo-1.2.4, forced firefox to use the patched libcairo.so via LD_LIBRARY_PATH and now firefox starts up happily in 8bit/256color mode on a remote connection (X Server: Citrix ICA 256 color mode). I cannot test later versions of cairo unfortunately, but at least you have this proof that the patch addresses the "depth 8" mode. Keep up the good work!
-Marek
Comment 67 Behdad Esfahbod 2008-01-04 04:41:09 UTC
Thanks Marek.  Can you attach a screenshot?!  I'm curious how it looks.
Comment 68 Marek Rouchal 2008-01-04 05:09:20 UTC
Created attachment 13517 [details]
screenshot of firefox on 256 color (depth 8) display
Comment 69 Frédéric Boiteux 2008-01-18 04:18:20 UTC
Hello,

  I can't use libcairo and all GTK applications of a Debian Etch (cairo 1.2.4) on my X11 NCD terminal (8bit colors) since a long time. I've tried to use patch #6762, and with it, applications launch but giving a lot of messages like :

No workaround for this pixel format: Visual: class=TrueColor, bpRGB=8, CM=8, r=7, g=38, b=c0
...
And no text appear !

  I've also tried patch #6819, but applications fail :
.../libcairo-1.2.4/src/cairo-image-surface.c:155: _cairo_format_from_pixman_format:  l'assertion « NOT_REACHED » a échoué.
Error: Cairo does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red   mask: 0x00000007
        Green mask: 0x00000038
        Blue  mask: 0x000000c0
Please file an enhacement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo

I'm not as lucky as Marek, and always stuck on old Debian Sarge from 2005 :-(
Comment 70 Ashish Yadav 2008-02-01 04:27:47 UTC
Hi,

I applied patch 11071 on cairo 1.4.10 on AIX 52. Build Firefox with the 1.4.10 devel RPM, however Firefox still crashed when started in 8 bit color mode.

Following was the error 

Error: Cairo 1.4.10 does not yet support the requested image format:
        Depth: 8
        Alpha mask: 0x00000000
        Red   mask: 0x00000000
        Green mask: 0x00000000
        Blue  mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
The assert subroutine failed: NOT_REACHED, file cairo-image-surface.c, line 199
obj-opt/dist/bin/run-mozilla.sh[36]: 217132 IOT/Abort trap(coredump)
Comment 71 Ashish Yadav 2008-02-06 01:33:49 UTC
Created attachment 14169 [details] [review]
Patch which worked on AIX 52

I tried to play around with the patch 11071, and this is what worked finally ( was able to run Firefox) in both Pseudo color and True color.

Looking for assistance in finding a suitable fix.
Comment 72 Behdad Esfahbod 2008-02-06 09:41:07 UTC
(In reply to comment #71)
> Created an attachment (id=14169) [details]
> Patch which worked on AIX 52
> 
> I tried to play around with the patch 11071, and this is what worked finally (
> was able to run Firefox) in both Pseudo color and True color.
> 
> Looking for assistance in finding a suitable fix.

Screenshots? Does this fix have the same artifacts as the last screenshot posted?
Comment 73 Stefan Schmidt 2008-02-09 21:21:16 UTC
i have a monochrome XTerminal NCD 16e, same blues:

collin:~> firefox 
Error: Cairo 1.4.14 does not yet support the requested image format:
       Depth: 1
       Alpha mask: 0x00000000
       Red   mask: 0x00000000
       Green mask: 0x00000000
       Blue  mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
firefox-bin: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-image-surface.c:199: _cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
Abort

;)

 Zap
Comment 74 Adrian Johnson 2008-02-20 01:23:16 UTC
*** Bug 12283 has been marked as a duplicate of this bug. ***
Comment 75 Carl Worth 2008-03-20 17:29:51 UTC
This bug is now fixed in the cairo 1.5.14 snapshot and the fix will appear in the imminent 1.6.0 cairo release.

Please test and let me know how things go.

-Carl
Comment 76 Frédéric Boiteux 2008-05-22 22:21:20 UTC
  Hello,

I've tested new 1.6.4 Cairo on a Debian Etch system (by recompiling the 1.6.4-1 Debian Sid package), and tested it on my X11 terminal : it works, but I still have a problem : all texts are painted with ugly colors (something like pink on purple (see attachment), and it's unusable. As i know there is different kinds of 8bits display, and that I tested this new Cairo version through Debian packaging, I wonder if the problem comes from Cairo, Debian packaging, GTK2 or something else. Is there something I can do to help to fix it ?
Comment 77 Frédéric Boiteux 2008-05-22 22:23:27 UTC
Created attachment 16702 [details]
Capture of part of my screen, with 'gkrellm' from new Cairo on the top and from an old no-Cairo version on the bottom
Comment 78 Marek Rouchal 2009-02-12 00:31:30 UTC
Created attachment 22849 [details]
screen capture of Firefox 2.0.0.17 with cairo-1.8.6 on 256 color X11 on Solaris 10 x86

I confirm that cairo-1.8.6 fixes this problem; rendering on 256-color X11 works OK now. Thanks to the developers, good job!
Comment 79 Boris Vinarsky 2017-07-14 14:24:13 UTC
Created attachment 132687 [details]
attachment-1164-0.html

Hello,

I am on brief vacation in Boston MA, back to work on Jul 17. I will read my email occasionally. If you need urgent response please indicate so. I will do my best to help.

Thank you,

Boris Vinarsky
Rambus IT - CRD
Comment 80 Don Lawrence 2017-07-14 14:57:10 UTC
Created attachment 132689 [details]
attachment-10479-0.html

I will be out of the office from Friday, 7/14/2017 through 7/23/2017. Please call Steven Anderson, (214)671-0424, for urgent matters. I will be monitoring Email periodicity.

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.