Re: [AD] Menus not honoring gui screen |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 2005-08-21 at 14:46 -0700, Chris wrote:
> >
> > Well, showing it on video bitmaps is just as dangerous :)
>
> No it isn't, because video bitmaps have mutex's associated with them through
> acquire/release. The two threads wouldn't be able to write to them
> simultaniously. There's no difference between "screen" and a second (or
> third) video bitmap, other than which one is currently visible.. as far as
> Allegro is concerned.
The problem is not acquire/release, but if you forget to call
scare_mouse. Whatever modifications to Allegros state you make, it will
interfer. E.g. clipping state.
> > > there's no mutex's in place), and showing it on a non-visible buffer is
> > > just wasteful.
> >
> > Well, not just wasteful, but impossible right now to do properly since
> > there's no scare_mouse.
>
> You can scare_mouse a video bitmap. When you check against screen, it checks
> against all other video bitmaps since video bitmaps are conceptually
> sub-bitmaps of the screen. Weren't their hacks put in place for
> non-single-surface VRAM pages for this? I could've sworn that's how it
> behaves. Checking _mouse_screen against screen with is_same_bitmap should be
> enough to allow it to work on video bitmaps.
>
> > I attached a patch which allows it.
>
> I thought we were going to disallow the mouse on a memory bitmap? Or rather,
> strongly discourage it, so programs that do use it won't break (though it
> could be argued they're already broken). There's no point in being able to
> scare the mouse from a memory bitmap, just like there's no point in showing
> it on a memory bitmap.
Yes, either disallow it, or use the patch - that's what I suggested in
the beginning. Just discouraging, but not applying the patch, won't do.
If I am allowed to show the mouse on a memory bitmap, then I must be
allowed to use scare_mouse to avoid droppings.
--
Elias Pschernig