Hi Denis, I've just now got around to implementing your suggested changes. I added a call to sched_yield() inside my loop to check the locks. Without it, performance seems to suffer. I don't know if there is a better way to handle this or not? I did see a note in the TODO about wanting to remove calls to sched_yield(), so if there is a better way, I'd be happy to look into it.
Attached is my patch. Let me know if anything needs to be changed.
Thanks,
Ryan Burns
--
Ryan Burns <[EMAIL PROTECTED]>
MontaVista Software, Inc.
On Thu, 1 Dec 2005 11:20:23 -0800
Ryan Burns <[EMAIL PROTECTED]> wrote:
> Thanks for the feedback.
> I wasn't aware the core surface code was being changed. I'll look into your
> suggestion today or tomorrow as a work around and submit a new patch.
>
> --
> Ryan Burns <[EMAIL PROTECTED]>
> MontaVista Software, Inc.
>
>
>
> On Thu, 1 Dec 2005 20:09:46 +0100
> Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
>
> > Quoting Ville Syrjälä:
> > > On Wed, Nov 30, 2005 at 04:09:30PM -0800, Ryan Burns wrote:
> > > > Hello,
> > > >
> > > > I've been working with directfb-0.9.24 with gtk-2.8.3, and just about
> > > > everytime I resize a window using the mouse, the application segfaults.
> > > > I've looked at the problem a bit, and it seems to me that there is a
> > > > race
> > > > condition between the input triggered dfb_surface_reformat (when
> > > > resizing), and IDirectFBSurface_FillRectangle and the functions it
> > > > calls.
> > > >
> > > > The application usually segfaults in Cop_to_Aop_32 while trying to write
> > > > to memory that was just freed in dfb_surface_reformat:
> > > >
> > > > #0 0xb7f9b010 in Cop_to_Aop_32 (gfxs=0x80a6d98) at
> > > > #../../../../src/gfx/generic/generic.c:147 1 0xb7facced in
> > > > gFillRectangle
> > > > #(state=0x1, rect=0xbffffc40) at
> > > > #../../../../src/gfx/generic/generic.c:7070 2 0xb7fb4e40 in
> > > > #dfb_gfxcard_fillrectangles (rects=0xbffffc40, num=1, state=0x80a7a38)
> > > > at
> > > > #../../../src/core/gfxcard.c:713 3 0xb7f82f3c in
> > > > #IDirectFBSurface_FillRectangle (thiz=0x80a79e0, x=0, y=0, w=538, h=621)
> > > > #at../../../src/display/idirectfbsurface.c:897
> > > > ...
> > > >
> > > >
> > > > For this specific instance, I was able to solve my problem by locking
> > > > the
> > > > surface manager in IDirectFBSurface_FillRectangle becuase thats the same
> > > > lock that dfb_surface_reformat uses. I notice in
> > > > dfb_gfxcard_fillrectangles it locks the state, but I dont see a way of
> > > > locking it in dfb_surface_reformat. I'm not real familiar with the
> > > > internals of DirectFB yet, so I don't know if this is an appropriate
> > > > solution. If it is, this sort of locking will need to be added in
> > > > several
> > > > places.
> > >
> > > The surface manager is already locked in dfb_gfxcard_state_acquire() but
> > > it is also released after the surfaces are locked. You could just change
> > > it release the lock in dfb_gfxcard_state_release(). However holding
> > > the lock across the accel operation(s) may not be a good idea.
> >
> > Yes, the surface manager shouldn't be locked all the time.
> >
> > > I think ideally we should check if the surface is locked before resizing
> > > it. But there is no skirmish used in the surface locking just reference
> > > counts for the buffers. And if we add a skirmish to the surface only one
> > > one user could lock the surface. That doesn't sound like a good idea so
> > > it could really use a rwlock type of thing.
> > > dfb_surface_{hard,soft}ware_lock() should use the read lock and
> > > dfb_surface_reformat() should use the write lock. There is also the
> > > problem of misbehaving applications that could keep the surface Lock()ed
> > > indefinitely.
> >
> > For now, it would be enough to wait for all lock counters being zero
> > in dfb_surface_reformat(). A simple loop that locks/checks(/unlocks)
> > might be sufficient.
> >
> > I'm still (actively) working on the new surface core code,
> > so it wouldn't be worth it to put too much effort into the old code.
> >
> > --
> > Best regards,
> > Denis Oliver Kropp
> >
> > .------------------------------------------.
> > | DirectFB - Hardware accelerated graphics |
> > | http://www.directfb.org/ |
> > "------------------------------------------"
>
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
directfb-resize.patch
Description: Binary data
_______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
