As discussed in the mailing list:
On 11/19/06, Erik Ohrnberger <Erik@echohome.org> wrote:
> > -----Original Message-----
> > From: firstname.lastname@example.org
> > [mailto:email@example.com] On Behalf Of Daniel Amelang
> > Sent: Sunday, November 19, 2006 11:10 PM
> > To: Vladimir Vukicevic
> > Cc: firstname.lastname@example.org; Erik@echohome.org
> > Subject: Re: [cairo] cairo-xlib-surface.c:402:
> > _swap_ximage_to_native:Assertion `NOT_REACHED' failed.
> > On 11/19/06, Vladimir Vukicevic <email@example.com> wrote:
> > > ----- Daniel Amelang <firstname.lastname@example.org> wrote:
> > > > On 11/18/06, Erik Ohrnberger <Erik@echohome.org> wrote:
> > > > > Generally, I'm running an X Window server emulator on
> > my Windows
> > > > > PC and pipe the display up there. The PC is set to 32
> > bit color
> > > > > depth, and when the DISLPAY env var is set to the IP of the
> > > > > Windows PC, that is when the applications fail with this error.
> > > > >
> > > > > Is there a setting someplace on the Linux side where I
> > can force a
> > > > > similar color depth as to the Option "Pixmap" "32" you
> > mention below?
> > > > >
> > > > > Thanks for the help, I really appreciate it.
> > > >
> > > > Hmmm...your question is outside the scope of this list, as your
> > > > problem is not cairo-related. You'll find better answers here
> > > > (especially the cygwin-xfree part):
> > >
> > > Well, it is sort of cairo related -- these X severs /are/
> > out there (including Xvnc and various others), and having cairo
> > assert out on them is not a good solution, IMO.
> > Yea, totally agree. I was reponding to his question about cygwin/X.
> > Sorry for the confusion, I didn't mean to imply that no one is going
> > to address the root of the problem. As I said in my first response
> > to Erik, I think this should problem should be in bugzilla and get
> > the proper attention.
> > Dan
> I have to admit that it's not cygwin/X, but an old program called
> VisionWare, and has served me faithfully for a long number of years.
Ah, sorry for jumping to conclusions. Unfortunately, I have no idea how to get
VisionWare's XVision into 32bpp mode. In fact, the following posting seems to
say that XVision doesn't support 32bpp Pixmaps at all :(
So I'm all out of ideas for workarounds. Sorry.
> Specific version information that could proove helpful:
> gtkmm-2.8.1, gtk+-2.6.10, cairo-0.1.6 works
> gtkmm-1.2.9-r2, gtk+-2.8.19, cairo-1.0.4 does not work
Cairo has changed so much from 0.1.6 to 1.0.4, especially in the place in xlib-
surface where the problem is. I can see the before and after code paths, but
it doesn't help solve the problem. Thing is, libpixman in now used in places
that previously only contained X calls. And it's pixman's lack of support for
24bpp that is the root of the problem. At least that's my understanding.
> Should I go and put this information in bugzilla? I'd be willing to
> do so, but I'd have to find out where the bugzilla site is.
Thanks for reporting this.
Carl/whoever is listening: could a quick stopgap measure be to do a conversion
from 24bpp to 32bpp before the image is handed over to pixman (or write a
conversion function in pixman that cairo-xlib can call)? Ideally, one would
want pixman to support 24bpp directly, but since that's a lot of work, and
this isn't a common case, it might be worth considering a slow and messy
approach. People don't call _acquire_(source|dest)_image in their display loop
cairo mailing list
Author: Chris Wilson <email@example.com>
Date: Wed Oct 15 10:21:05 2008 +0100
[xlib] Handle 4,20,24,28 depth XImages
Bug 9102 cairo doesn't support 24 bits per pixel mode on X11
is a reminder that that we need to support many obscure XImage formats.
With Carl's and Behdad's work to support psuedocolor we have a mechanism
in place to handle any format that is not natively handled by pixman. The
only piece we were missing was extending the swapper to handle all-known
formats and putting in defensive checks that pixels were correctly aligned
in accordance with pixman's requirements.