[cairo] Re: On recovery from errors in cairo (was: cairo reset)

[Kalle Vahlman]

2006/9/26, Mike Emmel <mike.emmel at gmail.com>:
> On 9/25/06, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:
> > 2006/9/25, Mike Emmel <mike.emmel at gmail.com>:
> > [snap]
> > > I've seen a lot of traffic on arm issues thats why I mentioned it.
> > > I just can't give numbers for the device I'm testing but most arm
> > > devices that use similar cpu's have about the same performance so
> > > it does not matter too much.
> >
> > There's a lot of other variables that might kill the performance, for
> > example the 770 suffers a lot from slow userspace-to-framebuffer
> > transfers. My little (animated) cairo test mistakenly drew directly on
> > the X11 surface (ie. window) at first and was dog slow, even though
> > it's pretty simple in structure. When I converted it to use a
> > backbuffer and only transferring areas that changed, the speed grew
> > exponentially. Admittedly the backbuffering helped on my laptop too,
> > but far less in comparison.
> >
>
> Hmm this may be a X11 problem generally I've seen the reverse.

It's more a limitation of hardware.

> Drawing to vram is fast since its on chip whild main memory to vram
> transfers are dog slow since many devices are crippled with a 16bit bus.

Exactly. And guess how much (dedicated) vram the 770 has?-)

> This is changing but the main memory bus is almost always still slow compared
> to desktop.  I'm guessing that for some reason there something wrong
> with the xserver/render implementation on the device.

Yes, the fact that there is not really hardware graphics acceleration
on it is wrong.

If I'm not totally wrong with my view of the system, the X and DSP
both write to the same clump of main memory designated as the
framebuffer area (X for X clients and DSP for decoded video frames
when watching videos). For this to actually work, X is told not to
update certain area of the framebuffer so the video data doesn't get
overwritten.

So if the framebuffer is not "closer" to the display in the sense it
normally would be. This means that if you say to X "draw these already
rendered pixels to screen" it's just one copy (in theory at least),
but if you instead say "draw this line here, that line there, fill the
area between" it's actually making X do more work updating the
framebuffer (and I would assume the display as a consequence) than the
single copy.

> This is of course a place where using my directfb backend for direct access
> is handy :)

...but not really beneficial on a 770, at least if I'm not completely
off with my understanding of the way things are arranged there.

> > We had a PXA290 at GUADEC and since our original demo ideas were
> > failing (due to driver problems), I ran the same Cairo demo there and
> > it was pretty good (this was before any of the real performance work
> > put to Cairo). The PXA290 is of course from the higher end and beats
> > 770 by far in numbers so it wasn't a big surprise really.
> >
> > But it was fun :)
> >
> I figured but the PXA290 is a nice cpu esp for power. The xscales where great
> for demos but are just now getting decent battery life they are still
> a power hog
> though.
> I think I'm getting off topic :)

Indeed :)

-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi