Hi Guennadi,
what I normally experience in these situations is that the driver is buggy.
You might wanna see what happens if you turn the frames around, though,
in other words, make it as if you are looking at the back buffer instead
of the front buffer. This is most easily done in fbdev_surface_pool.c,
where the function fbdevLock() generates the correct offset. "flipping"
is done by creating (for double buffering) a twice-screen-size buffer
which is flipped by "panning" up or halfway. look at the variable index;
if this is either 0 or 1 (as the case for double buffering) just swap
these as in index = 1 - index;
wonder what the result will be..
Niels
Guennadi Liakhovetski wrote:
On Thu, 10 Sep 2009, Daniel Mack wrote:
On Wed, Sep 09, 2009 at 08:49:11AM +0200, Guennadi Liakhovetski wrote:
Working with a Linux framebuffer driver, debugging its panning
functionality, I'm using df_fire and df_knuckles examples to test the
driver. df_fire runs fine. Yet another test-program also runs fine. But
with df_knuckles I'm seeing strange effects. It looks like the image
instead of just "smoothly" changing its shades, sometimes jumps to older
images, which do not belong to the smooth image chain. Can it be, that the
program doesn't switch buffers quite cleanly? Maybe it calculates in the
current buffer sometimes? Or what can be the reason?
What hardware is that?
SuperH
We've seen similar (as far as I can imagine from
your poetic explanation)
Glad you liked it:-) What I was trying to say, is that you would expect,
say, when the image is becoming lighter, a sequence of steps, in which
every next image is "slightly lighter" than the previous one. But what you
really see, is that sometimes (actually, practically after every image)
first a darker image appears shortly and only then the expected lighter
one.
effects on PXA platforms, and IIRC they
disappeared when we switched off frequency scaling.
Is off. And I can hardly imagine, that frequency scaling can produce
different images:-) What I can imagine though, that it can make images
visible, that otherwise stay invisible for the eye. Which would confirm my
theory, that the program really produces and displays those "wrong"
images, just that normally they are there for only a very short time,
probably way below the refresh period.
Might be something entirely different in your case though :)
In principle yes, it might...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
