[cairo] cairo-xlib-surface.c:402: _swap_ximage_to_native:Assertion `NOT_REACHED' failed.

[Damian Dixon]

On Tue, 21 Nov 2006 10:46:03 -0800, "Daniel Amelang" wrote:
>> Yes, but the issue is not the color depth, it's the bits per pixel.
It
>> is common to have 24-bit depth, yes, but less so to have 24bpp. Cairo
>> is broken on X Servers that use 24bpp for Pixmaps, but it works fine
>> on 32bpp servers that have 24-bit color depth.
>
>I wouldn't be very surprised to learn that that is the case.

Sorry I should have been a lot clearer about my use of depth and bpp.

I have a couple of X-Servers (6.4) running on Embedded hardware that use
5-6-5 format packed for the Pixmap. I have about 15 different X-Servers
running on a number of different OS's and processors (SPARC, PA-RISC II,
XScale, AMD x64, Intel, MIPS).

I do admit that some of the systems I have are long in the tooth but we
have people using these systems...

I could probably try cario with some of these combinations and provide
some feedback. I am just not sure if I can commit any significant time.


>> At least that is my understanding. I'm a little concerned that Carl
or
>> Keith hasn't chimed in to give a more authoritative response.
>
>I haven't tested it at all, so you're already speaking from a more
>authoritative position I think. :-)
>
>As far as the idea of converting when transferring to/from the X
>server, I think that's what the patches here do (originally written
>for the 8bpp case):
>
>	Cairo doesn't have 8-bit pseudocolor support
>	https://bugs.freedesktop.org/show_bug.cgi?id=4945
>

I have had a look at patch for 1.2.4 and most of the patch is fine in
that what the patch does in isolation looks ok with the following
observations:

There is a thread issue at the top of _get_clut_r3g3b2 that needs to be
sorted.

The patch should use XQueryColors rather then XQueryColor.

If the colourmap changes then there is no way of picking up the change.
Do we assume that the colourmap has been created specifically for cairo
and no-body else is using it? Possibly handle read only colour maps
differently from Read/Write colourmaps?

The colour matching may be an issue. What has been done looks reasonable
but I would like to see a reference to why this particular approach was
taken.

I don't know anything about Pixman and what formats it supports to say
if the checks made for the Visual class are sufficient. I suspect that
additional checks are required.



I doubt that 8-bit pseudocolor will be useable when anti-aliasing is
turned on. Dithering of colours will also introduce artefacts which may
not be acceptable.

I have found that when using 8-bit pseduocolour you want to be able to
specify the colour palette to ensure that you don't get any odd fills or
effects. In addition the colours used by the program need to contained
in the colourmap.


>I honestly haven't looked at the issue close enough to made a
>judgement call on whether those patches are in the right direction or
>not. I'd be glad to hear opinions from people here, (as well as
>results from testing these patches for the 24-bpp problem in this
>thread).
>
>-Carl

Regards
Damian