New Pixman Naming Scheme

[Soeren Sandmann]

Carl Worth <cworth at cworth.org> writes:

> But I would suggest that what we really want to have is:
> 
> 	pkg-config --cflags pixman
> 	-I/prefix/include/pixman
> 
> 	and the application would do #include <pixman.h>
> 
> I definitely don't see any advantage to starting off with a -1 as part
> of the name.

Do you see any disadvantages?

The advantage is that if we have to break API, then two versions
pixman-1 and pixman-2 can be installed in parallel. That way xorg and
cairo could upgrade to a new version separately.

Having a version number in the library name is just good practice
IMO. It doesn't hurt anything and it substantially reduces the pain
involved if an incompatible version has to be released.

The name does not imply that there are plans to actually release such
an incompatible version; it is just insurance against pain *if* it
becomes necessary.

Havoc has explained it here:

        http://www106.pair.com/rhp/parallel.html

> Is there some plan to be coming out with some pixman-2 at some point?
> Soon?
> 
> With the new cairo dependency on this library I'd like to see some
> plan in place, (and preferably a plan like cairo's: that is, the API
> isn't expected to change in any incompatible way in the foreseeable
> future). I should also sit down and do a thorough review of the pixman
> API to help with that.

I definitely agree that a plan should be in place. Off the top of my
head, here are some issues; there may be more:

* This API entry-point:

        pixman_region_set_static_pointers()

  is crack that only exists to avoid breaking X server ABI
  compatibility. The problem is that the X server has macros
  like this one:

        #define REGION_EMPTY(_pScreen, _pReg) \
        { \
            REGION_UNINIT(_pScreen, _pReg); \
            (_pReg)->extents.x2 = (_pReg)->extents.x1; \
            (_pReg)->extents.y2 = (_pReg)->extents.y1; \
            (_pReg)->data = &miEmptyData; \
        }

   and this one:

        #define REGION_NAR(reg) ((reg)->data == &miBrokenData)

   that encode the addresses of global variables. The
   pixman_set_static_pointers() API is a way for the X server to pass
   the addresses of miEmptyData etc. so that pixman doesn't try to free
   them etc.

   Fixing this would require changes to the X server video driver
   ABI. Maybe we can do this for the next X server version, not sure.

*  There is a desire to have 32 bit regions instead of 16 bits as we
   have now. This is also an ABI change for the X server, but is
   probably otherwise harmless.

*  There is talk about moving to 24.8 coordinates.

*  Threads. At some point in the not-too-distant future the compositing
   routines in pixman should become multi-threaded to take advantage
   of multi-core CPU's.

   I have also seen image malloc/free show up on profiles. A small
   cache of 3-4 pre-allocated images would be beneficial, but this
   requires locking. I actually had such a cache for a while, but had
   to remove it since it broke multi-threaded cairo applications.

   This may or may not affect ABI.

*  We should make sure the pixman_format_code_t enum is good enough for
   all possible future formats. There is some discussion in
   pixman/TODO about this.

   Some formats we will likely need:

        ARGB/ABGR with 16/32/64 bit integer/floating channels
        YUV2,
        YV12

   It should also be considered how to handle color space issues. Most
   likely the colorspace would just be a separate property on an image,
   but we should be sure that's good enough.


Soren