[cairo] Problems porting to embedded ARM9 platform - only rectangles are visible

[Daniel Amelang]

On 12/21/06, Luke Diamand <luke at diamand.org> wrote:
> Daniel Amelang wrote:
>
> > > I'm trying to get cairo 1.3.8 running on an embedded ARM9 platform (no
> > > FPU; gcc 3.4, little-endian).
> > >
> > > I find that only rectangles get displayed correctly. Diagonal lines and
> > > arcs never appear. The same code works fine on x86/linux.
> > >
> > > I ran the fill_rule test, and it said:
> > >
> > > 4224 pixels differ (with maximum difference of 255) from reference image
> > > TEST: fill-rule TARGET: image FORMAT: argb32 OFFSET: 0 RESULT: FAIL
> > > fill-rule-image-argb32 [0]:     FAIL
> >
> > That's pretty bizarre. We already have cairo 1.3.8 running properly on
> > the 770, which has pretty much the same hardware specs. I'll fire mine
> > up later to see if we missed a "make test" back there.
>
> I thought it was bizarre too!
>
> >
> > Can you tell us more about your system? Hardware and software? What
> > are the major differences when compared to the 770 and Maemo?
>
> The most obvious difference is that we are using a proprietary OS.
>
> In my test code though, cairo only uses a handful of external calls -
> malloc, qsort, memset,  and so-on. I am confident these behave in a
> standard fashion.
>
> The floating point code is perhaps different. On the 770 I guess the
> Linux ARM floating point code is used. I currently use the gcc 3.4.6
> distributed assembler routines which seem to behave slightly
> differently. For example, converting a -ve double to an unsigned returns
> 0 rather than the bitpattern of the corresponding -ve integer.
>
> However, I have also tried floating point code derived from softfloat
> (so same derivation as ARM/Linux) and this has the same problem [1].
>
> The code is all being executed in ARM mode, rather than thumb. I'd hope
> that wouldn't make any difference.
>
> I've simply taken the config.h generated by configuring for an ARM. But
> it's possible that there is somewhere some #ifdef code that looks at
> defines generated by the compiler.
>
> After that, the hardware is just a standard ARM920T. It has some
> hardware 2d acceleration, but that's not being used right now.

Any updates on this Luke? Since I'm responsible for some strange
floating-point optimizations in cairo, I'm interested in making sure
that what you're seeing isn't my fault :)

BTW, you should be aware that the config.h that is generated for one
ARM system might not be correct for another. Take float word order for
instance.

>
> Luke

Dan