Re: Re: surface locking

Welcome back Marc,

see below...

On Tue, 2003-08-12 at 06:16, Marc Str=C3=A4mke wrote:
> Darren V Hart wrote:
> > We need to discuss how we want to handle backends that require surface
> > locking prior to direct access.  I think the API should state that
> > put_pixel*() and get_pixel*() should be called with the surface locked,
> > and that their behavior is undefined if the surface is not locked.  Thi=
s
> > will allow the high level drawing routines to call lock and unlock as
> > necessary.  ie draw_poly calls draw_line, but the user may call
> > draw_line as well, so we must be able to recursively call lock without
> > blocking.  To draw a single pixel, the use must call draw_pixel*() whic=
h
> > must lock, call put_pixel, and unlock.
> >=20
> > It may be of use to provide a surface::lock(void) to simply lock the
> > surface and not fill in the double pointer buf field etc.
> >=20
> > Comments welcome.
>=20
> I think we are talking about two different kind of locks here, the type=20
> i mentioned when we invented the API was for direct memory access to=20
> graphic memory, so the biggest purpose is getting the pointer, the kind=20
> you are thinking of is backend specific and needs no api. (I M O)
>=20



Actually it is sort of the same thing, both locks prepare for direct
pixel access, the only difference is WHO it prepares it for.  lock(void)
prepares it for the library, lock(...) prepares it for the user.

If we were to leave the lock(void) out of the API, then the SDL backend
(for example) would have to override EVERY drawing routine like this:

virtual draw_routine(...)
{
	SDL_LockSurface(sdl_surface_);
	surface_impl<surface_sdl>::draw_routine(...);
	SDL_UnlockSurface(sdl_surface_);
}

Which I guess isn't terrible.  Thoughts?

Darren

>=20
>=20
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk