oic, now that makes sense.
I did a test on fbdev and I got the same response as you.
only on the "Lock" will DirectFB assign memory, and since you get a
C-pointer this is CPU-accessible memory.
then after Unlock, the FillRectangles wants GPU memory.
In principle the GPU memory is mmap'd as well, so you need only one
allocation - however, the first access (CPU only) leads to DirectFB
taking the approach of requesting SYSTEM or SHARED memory, and only the
HW accel option afterwards changes this to memory from the FBDEV pool,
leading to a buffer transfer (in other words, the allocation is copied
to the new location, it is not a flip).
The slightly non-intuitive VIDEO_ONLY at surface creating will alleviate
this for this case in particular.
Greets
Niels
Lionel Landwerlin wrote:
Hello Niels,
On Wed, Feb 17, 2010 at 9:00 PM, Niels Roest <ni...@directfb.org
<mailto:ni...@directfb.org>> wrote:
Strange.
Rewriting your tests a bit towards C, I do not experience this
behaviour...
I only have the behavior if the FillRectangle operation is accelerated.
Do you try that in this setup ?
ptr before == ptr after, and after a flip, it changes.
Note that it is not imposed that the ptr's are always equal;
DirectFB reserves the right to move non-locked memory areas, but I
suspect that this is not the case here.
Greets
Niels
Lionel Landwerlin wrote:
Hello everyone,
I'm using surface locks for some custom graphical engine
tests, and don't understand the following behavior of directfb :
layer->CreateSurface(&surface, DOUBLE_BUFFERED)
surface->Lock (&ptr, CPU_READ|CPU_WRITE);
Here directfb return a ptr = 0x42424242 for example.
Then I execute the following steps :
surface->Unlock()
surface->FillRectangle(0, 0, 42, 42);
surface->Lock(&ptr, CPU_READ|CPU_WRITE);
Here ptr has changed from its previous value.
Why ? I didn't require a Flip.
Should I own the lock all the time ?
Thanks for answers.
--
Lionel Landwerlin
------------------------------------------------------------------------
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org <mailto:directfb-dev@directfb.org>
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
