page flipping

326 views
Skip to first unread message

Ben Leslie

unread,
Nov 2, 2008, 12:11:02 AM11/2/08
to android...@googlegroups.com
The current documentation implies that everything should work on
devices where double buffering (panning) isn't supported by the
underlying driver.

However, swapBuffers() doesn't actually seem to support PAGE_FLIP:

uint32_t EGLDisplaySurface::swapBuffers()
{
if (!(mFlags & PAGE_FLIP)) {
return 0;
}
....
}

If I add a memcpy() in there things seem to work correctly (at least
on the neo 1973).

Do I need to add this, or should non page flip work some other way?

Cheers,

Benno

Sean McNeil

unread,
Nov 2, 2008, 12:47:06 AM11/2/08
to android...@googlegroups.com
Ben Leslie wrote:
> The current documentation implies that everything should work on
> devices where double buffering (panning) isn't supported by the
> underlying driver.
>

Page flipping is a little odd. It actually does a scroll which can be
very noticeable on some graphics chips. It can have severe performance
issues as well. I think it was also incomplete in that it swapped
between video memory and allocated memory when flipping isn't supported.
At times, the allocated memory appeared to not get updated. I haven't
looked to see if that was fixed.

If you disable flipping altogether and just set the 2 array values to
the same buffer, then it works just fine. There are some small issues
left, though, with the dialogs. Lots of repainting you can see when it
blurs the background and pops up the dialog.

Ben Leslie

unread,
Nov 2, 2008, 12:58:15 AM11/2/08
to android...@googlegroups.com
On Sun, Nov 2, 2008 at 3:47 PM, Sean McNeil <seanm...@gmail.com> wrote:
>
> Ben Leslie wrote:
>> The current documentation implies that everything should work on
>> devices where double buffering (panning) isn't supported by the
>> underlying driver.
>>
>
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips. It can have severe performance
> issues as well.

Yeah I noticed that. I'm not sure if Linux has a better way of
performing double buffering.

>I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.

That is what the set up code implies, but the page flip code is
stubbed out to return zero (as far as I can tell).

> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine.

OK, that approach is possibly better doing the memcpy.

>There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.

That would be what I would expect.

I'll need to look at the 1973 hardware to see if there is a way of
implementing double buffering with hopefully just a register write.
(Or maybe I'll just get a freerunner and be done with it :)

Cheers,

Benno

Brian Swetland

unread,
Nov 2, 2008, 1:01:06 AM11/2/08
to android...@googlegroups.com
[Sean McNeil <seanm...@gmail.com>]

> Ben Leslie wrote:
> > The current documentation implies that everything should work on
> > devices where double buffering (panning) isn't supported by the
> > underlying driver.
> >
>
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips. It can have severe performance
> issues as well. I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.
> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine. There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.

We haven't been doing any development on hardware without pageflipping
support. On the emulator and msm7k ports, the pan operation we use to
flip works well, but I think this is another area where we're going to
have to build some more flexibility into the system -- obviously what's
there now is not working everywhere and I suspect there may not be just
two options (flip/no-flip), but some variation in how flipping is handled.

Brian

Sean McNeil

unread,
Nov 2, 2008, 1:06:25 AM11/2/08
to android...@googlegroups.com

One thing on my list that will significantly improve the user experience
with the Freerunner is to use some of its coprocessors. For instance, it
has an openGL capable graphics chip that would help. It also has an mp4
decoder that would smooth out the video quite nicely. Right now it is a
little blocky.

Not to mention it has Wifi. I forget if the gta01 has accelerometers,
but its nice to have video flip over when you turn the phones orientation.


> Cheers,
>
> Benno
>
> >
>

McHarg Chris

unread,
Nov 2, 2008, 2:41:50 AM11/2/08
to android...@googlegroups.com
Hi

On 2008/11/02, at 14:01, Brian Swetland wrote:
> We haven't been doing any development on hardware without pageflipping
> support. On the emulator and msm7k ports, the pan operation we use to
> flip works well, but I think this is another area where we're going
> to
> have to build some more flexibility into the system -- obviously
> what's
> there now is not working everywhere and I suspect there may not be
> just
> two options (flip/no-flip), but some variation in how flipping is
> handled.

That reminds me... when looking at the i.MX31 fb flickering problem a
while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which
calls fb_set_par etc along with fb_pan_display) instead of
FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing
it that way?

Now that I have the code(!), it seems just swapping to FBIOPAN_DISPLAY
will work ok, so I might give that a try next week.

http://git.source.android.com/?p=platform/frameworks/base.git;a=blob;f=libs/ui/EGLDisplaySurface.cpp;h=ea245f5e0d8031c194cb3c208dcfce922bbf2c60;hb=HEAD#l179

Matt Reimer

unread,
Nov 3, 2008, 4:56:14 PM11/3/08
to android...@googlegroups.com
On Sat, Nov 1, 2008 at 8:58 PM, Ben Leslie <be...@benno.id.au> wrote:
> I'll need to look at the 1973 hardware to see if there is a way of
> implementing double buffering with hopefully just a register write.
> (Or maybe I'll just get a freerunner and be done with it :)

If it's using the s3c24x0's lcd controller, you could do it by messing
with LCDBASEU/LCDBASEL in the LCDSADDR1/2 registers.

Matt

Mathias Agopian

unread,
Nov 3, 2008, 8:58:28 PM11/3/08
to android-porting
Hi everyone,

On Nov 1, 11:41 pm, McHarg Chris <chris.mch...@gmail.com> wrote:
> Hi
>
> On 2008/11/02, at 14:01, Brian Swetland wrote:
>
> > We haven't been doing any development on hardware without pageflipping
> > support.  On the emulator and msm7k ports, the pan operation we use to
> > flip works well,  but I think this is another area where we're going  
> > to
> > have to build some more flexibility into the system -- obviously  
> > what's
> > there now is not working everywhere and I suspect there may not be  
> > just
> > two options (flip/no-flip), but some variation in how flipping is  
> > handled.
>
> That reminds me... when looking at the i.MX31 fb flickering problem a  
> while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which  
> calls fb_set_par etc along with fb_pan_display) instead of  
> FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing  
> it that way?

I did it this way because some of the drivers on some hardware we used
didn't support FBIOPAN_DISPLAY (and still don't). It looks like
FBIOPAN_DISPLAY is often not implemented in comparison to
FBIOPUT_VSCREENINFO.

Ideally the code there should try FBIOPAN_DISPLAY and if that doesn't
work, revert to FBIOPUT_VSCREENINFO.

> Now that I have the code(!), it seems just swapping to FBIOPAN_DISPLAY  
> will work ok, so I might give that a try next week.

It need to be done in a way that the current behavior will still work
when FBIOPAN_DISPLAY is not supported.

> http://git.source.android.com/?p=platform/frameworks/base.git;a=blob;...

Mathias

Mathias Agopian

unread,
Nov 3, 2008, 9:01:23 PM11/3/08
to android-porting
Hi Ben,
You are perfectly right. The code is incomplete and doesn't work
without page-flipping.
It is intended to work by performing a memcpy() as you have suggested.

We have actually fixed the non-page flipping case; but the code has
not been submitted yet.

Mathias

Mathias Agopian

unread,
Nov 3, 2008, 9:06:58 PM11/3/08
to android-porting
Hello,

On Nov 1, 8:47 pm, Sean McNeil <seanmcne...@gmail.com> wrote:
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips.

Could you elaborate? The intention is that the scrolling is always
performed synchronized with the refresh. Since it scrolls by a full
page, it is equivalent to swapping to another buffer. In which case
will it cause artifacts or be "noticeable"?

> It can have severe performance

Can you precise in which scenarios it can have a severe performance
impact?

> issues as well. I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.
> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine.

This will cause flickering and tearing, unfortunately; which is not
acceptable for games or animations in the UI.

> There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.

This is why a memcpy() is unfortunately, needed when page flipping is
not supported in hardware. The assumption here, is that hardware
manufacturers control their drivers and will implement the features
needed for proper graphics quality and performance.

Mathias


Sean McNeil

unread,
Nov 3, 2008, 9:42:12 PM11/3/08
to android...@googlegroups.com
Mathias Agopian wrote:
> Hello,
>
> On Nov 1, 8:47 pm, Sean McNeil <seanmcne...@gmail.com> wrote:
>
>> Page flipping is a little odd. It actually does a scroll which can be
>> very noticeable on some graphics chips.
>>
>
> Could you elaborate? The intention is that the scrolling is always
> performed synchronized with the refresh. Since it scrolls by a full
> page, it is equivalent to swapping to another buffer. In which case
> will it cause artifacts or be "noticeable"?
>

As far as I can tell, it isn't suppose to provide immediate refresh of
the screen, so there are graphics chips that smoothly move to the
alternate graphical area. On the Openmoko GTA01, you can see what looks
a little like a shift in the view and the top bar is ghosted near the
bottom of the display. On the Openmoko GTA02, it just runs exceedingly
slow. I'm not sure if it is the Glamo chip or the driver. I'll have to
check with my companion, but during early development we saw problems on
the TI OMAP2-Zoom reference flatform as well.

>
>> It can have severe performance
>>
>
> Can you precise in which scenarios it can have a severe performance
> impact?
>

On the GTA02, all graphics are slowed down significantly. The world time
zone, for instance, it is practically unbearable.

>
>> issues as well. I think it was also incomplete in that it swapped
>> between video memory and allocated memory when flipping isn't supported.
>> At times, the allocated memory appeared to not get updated. I haven't
>> looked to see if that was fixed.
>>
>> If you disable flipping altogether and just set the 2 array values to
>> the same buffer, then it works just fine.
>>
>
> This will cause flickering and tearing, unfortunately; which is not
> acceptable for games or animations in the UI.
>

Indeed. Also, as mentioned below dialogs don't work well either.

>
>> There are some small issues
>> left, though, with the dialogs. Lots of repainting you can see when it
>> blurs the background and pops up the dialog.
>>
>
> This is why a memcpy() is unfortunately, needed when page flipping is
> not supported in hardware. The assumption here, is that hardware
> manufacturers control their drivers and will implement the features
> needed for proper graphics quality and performance.
>

It also assumes what scrolling the display buffer will do. I should
think this is accepted practice that if you have a duplicate screen size
not viewed you might expect it should not do a smooth transition, but
instantly switch buffers. This is not, however, what the definition of
panning is. To pan is to transition over time. It is typically used to
allow for a larger graphics area that is written and you can move your
viewing port around that area.

> Mathias
>
>
>
> >
>

Chris

unread,
Nov 4, 2008, 12:53:56 PM11/4/08
to android-porting
On x86 devices with Intel integrated graphics (e.g., 865, 945, etc),
FBIOPAN_DISPLAY seems to result in an instantanous buffer switch. On
some of these devices however, when one tries to do
FBIOPUT_VSCREENINFO, it will be quite slow because it actually
reapplies all the fields instead of recognizing the changed fields and
applying them. This can result in an unfortunate blinking effect on
each frame update. In my experience, on x86 it is best to check if
FBIOPAN_DISPLAY is supported and use it if it is supported. If not,
drop back to FBIOPUT_VSCREENINFO. If neither works because setting up
the framebuffer for virtual panning failed or the driver simply does
not support it the memcpy trick seems to be functionally correct but
will suck extra cycles on every screen update.

On x86 anyway, if you would like to pan slowly instead of
instanteously over a large virtual framebuffer, I think you would have
to issue a series of FBIOPAN_DISPLAY calls (i.e., you use the ioctl to
implement a sw controlled panning fuction not to have the hardware pan
at its own pace).

I am not sure that it will be possible to have a completely platform
independent code sequence that will be effective on all platforms of
interest to everyone. Based on this discussion, I suspect that the
"best way to swap buffers without tearing or wasting clocks" will vary
with platform. Are there ideas for how to do platform ifdefs or some
other mechanism to avoid dueling tweaks to this part of the code?

Regards,
Chris
> > Mathias- Hide quoted text -
>
> - Show quoted text -

Mathias Agopian

unread,
Nov 4, 2008, 1:24:20 PM11/4/08
to android-porting
Hi Chris,

On Nov 4, 9:53 am, Chris <chris.l.elf...@intel.com> wrote:
> On x86 devices with Intel integrated graphics (e.g., 865, 945, etc),
> FBIOPAN_DISPLAY seems to result in an instantanous buffer switch.  On
> some of these devices however, when one tries to do
> FBIOPUT_VSCREENINFO, it will be quite slow because it actually
> reapplies all the fields instead of recognizing the changed fields and
> applying them.  This can result in an unfortunate blinking effect on
> each frame update.  In my experience, on x86 it is best to check if
> FBIOPAN_DISPLAY is supported and use it if it is supported.  If not,
> drop back to FBIOPUT_VSCREENINFO.  If neither works because setting up
> the framebuffer for virtual panning failed or the driver simply does
> not support it the memcpy trick seems to be functionally correct but
> will suck extra cycles on every screen update.
>
> On x86 anyway, if you would like to pan slowly instead of
> instanteously over a large virtual framebuffer, I think you would have
> to issue a series of FBIOPAN_DISPLAY calls (i.e., you use the ioctl to
> implement a sw controlled panning fuction not to have the hardware pan
> at its own pace).

My take (and by experience), is that phone manufacturers will
implement the ioctl the "right way" for the features we want. The real
problem is that the linux fb driver doesn't have a well defined (or at
least not well documented) API and allow each driver to do things
differently. Reading fb.h, I see no guidance as to what these ioctl
should do exactly.
Also, I don't think we should put to much effort in working with buggy
drivers -- it is best to fix the driver instead; Most fb drivers don't
implement vsync properly for instance, but it is a *must have* for the
Android UI.

> I am not sure that it will be possible to have a completely platform
> independent code sequence that will be effective on all platforms of
> interest to everyone.  Based on this discussion, I suspect that the
> "best way to swap buffers without tearing or wasting clocks" will vary
> with platform.  Are there ideas for how to do platform ifdefs or some
> other mechanism to avoid dueling tweaks to this part of the code?

We have started to work on a modular hardware abstraction mechanism,
which has not yet been submitted. It will handle platform specific
things such as basic graphics acceleration, sensors, camera, etc...
I suppose, we could create a "display" hardware module with a well
defined and documented API that will handle the gory details of a
particular fb driver. I'm wondering if it is not overkill though.

Mathias

Chris

unread,
Nov 4, 2008, 10:06:00 PM11/4/08
to android-porting
Matias writes:
> We have started to work on a modular hardware abstraction mechanism,
> which has not yet been submitted. It will handle platform specific
> things such as basic graphics acceleration, sensors, camera, etc...
Interesting. Hopefully, it can be somewhat organic with additional
components (like some of these graphics bits) added as needed over
time. I would hate to overdesign such an interface up-front with all
the "gory details" only to find that just a few hooks are needed.

Matias writes:
> My take (and by experience), is that phone manufacturers will
> implement the ioctl the "right way" for the features we want. The real
> problem is that the linux fb driver doesn't have a well defined (or at
> least not well documented) API and allow each driver to do things

Good point. Thinking beyond the phone, into the x86 MID and up into
netbook/laptop and desktop, I could imagine running on framebuffer
devices to which source is unavailable to customize the ioctl. In
addition even when the driver is open source (hopefully the common
case), in many cases on x86 we try to use device drivers in as close
to an OOB (out of the box) as possible and work around any issues in
the user mode code (limiting the number of projects into which changes
need to be deployed... which may have other consumers that require
different behavior). It will be interesting to find the right balance
between putting patches such as this into Android projects (and
extending the hardware abstraction layer) versus driving them into
upstream projects. Admittedly, the Android kernel is an Android
project but I assume that a goal will be to minimize to some extent
its divergence from the root Linux kernel.

Thx,
Chris
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

markgross

unread,
Nov 4, 2008, 10:06:30 PM11/4/08
to android-porting


On Nov 4, 10:24 am, Mathias Agopian <pixelflin...@google.com> wrote:
I think its important to point out that Andoid as an open source
project is not limited to just handsets.

>
> > I am not sure that it will be possible to have a completely platform
> > independent code sequence that will be effective on all platforms of
> > interest to everyone. Based on this discussion, I suspect that the
> > "best way to swap buffers without tearing or wasting clocks" will vary
> > with platform. Are there ideas for how to do platform ifdefs or some
> > other mechanism to avoid dueling tweaks to this part of the code?
>
> We have started to work on a modular hardware abstraction mechanism,
> which has not yet been submitted. It will handle platform specific
> things such as basic graphics acceleration, sensors, camera, etc...
> I suppose, we could create a "display" hardware module with a well
> defined and documented API that will handle the gory details of a
> particular fb driver. I'm wondering if it is not overkill though.

Some HAL types of abstractions will not be overkill as we see more and
more platforms, architectures and uses of android. BTW will google
have some design discussion on these or just drop the code on the
public when its ready?

--mgross

Yasushi SHOJI

unread,
Nov 12, 2008, 6:40:44 AM11/12/08
to android-porting
On Nov 4, 10:58 am, Mathias Agopian <pixelflin...@google.com> wrote:
> On Nov 1, 11:41 pm,McHargChris <chris.mch...@gmail.com> wrote:
[...]
> > That reminds me... when looking at the i.MX31 fb flickering problem a
> > while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which
> > calls fb_set_par etc along with fb_pan_display) instead of
> > FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing
> > it that way?
>
> I did it this way because some of the drivers on some hardware we used
> didn't support FBIOPAN_DISPLAY (and still don't). It looks like
> FBIOPAN_DISPLAY is often not implemented in comparison to
> FBIOPUT_VSCREENINFO.
>
> Ideally the code there should try FBIOPAN_DISPLAY and if that doesn't
> work, revert to FBIOPUT_VSCREENINFO.

I noticed that QEMU uses SDL and SDL use only FBIOPAN_DISPLAY for
flipping.

Does it means that pre-built SDL lib for Android emulator is modifiled
to match
this broken behavior?
--
yashi

David Turner

unread,
Nov 12, 2008, 7:36:54 AM11/12/08
to android...@googlegroups.com
the SDL used in the Android emulator (a QEMU derivative) only uses standard X11 to
display things, so it certainly doesn't use FBIOPAN_DISPLAY.

Meanwhile, I think that's totally unrelated to your issue.

Benno

unread,
Nov 17, 2008, 2:39:37 AM11/17/08
to android-porting
Thanks Mathias! Good to see I'm not completely off track!

Cheers,

Benno

Sean McNeil

unread,
Nov 17, 2008, 3:11:20 AM11/17/08
to android...@googlegroups.com

This is irrelevant on Freerunner now as I've implemented page flipping
in the kernel. I still have to change to use FBIOPAN_DISPLAY, though, as
the other ioctl does a complete refresh of settings and causes flashing.

Mathias Agopian

unread,
Nov 17, 2008, 4:27:19 AM11/17/08
to android...@googlegroups.com

Sounds good.
Eventually, we'll need to abstract this out because there is no way to
know which ioctl to use. And in fact, one could imagine a board
without a /dev/graphics/fb driver at all. It sounds more and more like
a good candidate for the upcoming hardware abstraction layer.

mathias

Chris

unread,
Nov 17, 2008, 1:03:21 PM11/17/08
to android-porting
I agree that longer term, this is a good candidate for hardware
abstraction. For the nearer term, I do have a patch to
EGLDisplaySurface.cpp that prefers PAN and if PAN is unavailable drops
back to PUT_VSCREENINFO. This patch also provides a fallback to
memcpyh if necessary. The patch is needed on some x86 platforms. We
are working thru the final steps of our internal legal reviews to let
us contribute to Android Open source (see
http://groups.google.com/group/android-porting/msg/bb9e38d8caa62441)
and hope I hope we can start submitting soon.

Thanks,
Chris

On Nov 17, 1:27 am, Mathias Agopian <pixelflin...@google.com> wrote:
> mathias- Hide quoted text -

Ben Leslie

unread,
Nov 18, 2008, 12:23:28 AM11/18/08
to android...@googlegroups.com

Sure, I think it is still worth fixing for people porting to other
platforms. Either the code should be fixed, or things should error out
much earlier if the drivers doesn't have the correct capabilities.

Cheers,

Benno

Reply all
Reply to author
Forward
0 new messages