(Proposal) Callbacks for surfaces

[Charles_Swain]

I’ve always thought of the userdata field of the SDL_Surface struct as
wasteful, because I couldn’t think of a proper use for it without
having to implement my own conflicting API for surfaces above SDL’s
(to handle the content of the userdata field, and they were
conflicting because individual usage of SDL’s API with that surface
would undermine the integrity of mine). I also did not want to
implement a new API atop SDL’s that exposed a parent struct to the
pointer to the SDL_Surface struct to user code, because it would
require an entirely new API on my part. Then, while riding home from
school by bus, I thought of callbacks.

We could add a new field to the SDL_Surface struct that contains a
function pointer that is called by SDL’s API and user code at specific
points in execution to yield some behavior.

int (user_callback)(SDL_Surface, Uint32, void*);

The first argument would be a pointer to the corresponding surface.
The second argument would be the circumstance which could be before
freeing the surface in a call to SDL_FreeSurface(), after creating the
surface (with an equivalent function to SDL_CreateRGBSurface() or
SDL_CreateRGBSurfaceFrom() that takes the callback to initialize with
as an argument), before and after blitting or scaling, format changes,
some user code specific thing, etc (it’s whatever you can think of).
The third argument would be a pointer to whatever extra data that is
necessary depending on the circumstance, such as the arguments to the
SDL API function that was called which invoked this function, or
nothing (NULL) if suitable for the circumstance. Return values could
be the same across the board or circumstance specific.

[Jonas_Kulla]

2014-04-28 21:58 GMT+02:00 Charles Swain :

I’ve always thought of the userdata field of the SDL_Surface struct as
wasteful, because I couldn’t think of a proper use for it without
having to implement my own conflicting API for surfaces above SDL’s
(to handle the content of the userdata field, and they were
conflicting because individual usage of SDL’s API with that surface
would undermine the integrity of mine). I also did not want to
implement a new API atop SDL’s that exposed a parent struct to the
pointer to the SDL_Surface struct to user code, because it would
require an entirely new API on my part. Then, while riding home from
school by bus, I thought of callbacks.

We could add a new field to the SDL_Surface struct that contains a
function pointer that is called by SDL’s API and user code at specific
points in execution to yield some behavior.

int (user_callback)(SDL_Surface, Uint32, void*);

The first argument would be a pointer to the corresponding surface.
The second argument would be the circumstance which could be before
freeing the surface in a call to SDL_FreeSurface(), after creating the
surface (with an equivalent function to SDL_CreateRGBSurface() or
SDL_CreateRGBSurfaceFrom() that takes the callback to initialize with
as an argument), before and after blitting or scaling, format changes,
some user code specific thing, etc (it’s whatever you can think of).
The third argument would be a pointer to whatever extra data that is
necessary depending on the circumstance, such as the arguments to the
SDL API function that was called which invoked this function, or
nothing (NULL) if suitable for the circumstance. Return values could
be the same across the board or circumstance specific.

What is the use case for this?

[Charles_Swain]

Textures.On 4/28/14, Jonas Kulla wrote:

2014-04-28 21:58 GMT+02:00 Charles Swain <@Charles_Swain>:

I’ve always thought of the userdata field of the SDL_Surface struct as
wasteful, because I couldn’t think of a proper use for it without
having to implement my own conflicting API for surfaces above SDL’s
(to handle the content of the userdata field, and they were
conflicting because individual usage of SDL’s API with that surface
would undermine the integrity of mine). I also did not want to
implement a new API atop SDL’s that exposed a parent struct to the
pointer to the SDL_Surface struct to user code, because it would
require an entirely new API on my part. Then, while riding home from
school by bus, I thought of callbacks.

We could add a new field to the SDL_Surface struct that contains a
function pointer that is called by SDL’s API and user code at specific
points in execution to yield some behavior.

int (user_callback)(SDL_Surface, Uint32, void*);

The first argument would be a pointer to the corresponding surface.
The second argument would be the circumstance which could be before
freeing the surface in a call to SDL_FreeSurface(), after creating the
surface (with an equivalent function to SDL_CreateRGBSurface() or
SDL_CreateRGBSurfaceFrom() that takes the callback to initialize with
as an argument), before and after blitting or scaling, format changes,
some user code specific thing, etc (it’s whatever you can think of).
The third argument would be a pointer to whatever extra data that is
necessary depending on the circumstance, such as the arguments to the
SDL API function that was called which invoked this function, or
nothing (NULL) if suitable for the circumstance. Return values could
be the same across the board or circumstance specific.

What is the use case for this?

[Charles_Swain]

Just realized that there is a better way to describe possible use cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

[Alex_Barry]

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which doesn’t
make sense in terms of an open-source product. If you are trying to build
a different renderer (since you mention OpenGL in use with surfaces), why
not let everyone use it as an optional backend? Also, if you want to use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be used
for. Do you callbacks for pre- and post- function calls for absolutely all
functions that relate to SDL_Surface? I don’t think you realize that this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone. For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full SDL
community, they may be relying on the person suggesting the change to try
writing a patch rather than making an open suggestion for someone else to
implement. Good luck :)On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain wrote:

Just realized that there is a better way to describe possible use cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Charles_Swain]

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which doesn’t
make sense in terms of an open-source product. If you are trying to build
a different renderer (since you mention OpenGL in use with surfaces), why
not let everyone use it as an optional backend? Also, if you want to use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be used
for. Do you callbacks for pre- and post- function calls for absolutely all
functions that relate to SDL_Surface? I don’t think you realize that this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone. For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full SDL
community, they may be relying on the person suggesting the change to try
writing a patch rather than making an open suggestion for someone else to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain <@Charles_Swain>wrote:

Just realized that there is a better way to describe possible use cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alex_Barry]

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

Your example probably doesn’t really have much use to people, since they
will write their own wrappers, since user-data may never be allocated the
same for different SDL_Surfaces in the same application. I don’t know that
it’s in the scope of SDL to manage user data - that’s why it’s user data.
What sort of data is being changed on a per-function basis that undermines
your intended usage? It’s possible that you are approaching your software
problem from the wrong direction, which you may want to consider, but
without seeing any code, it’s difficult to say one way or another.

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Sorry, I don’t mean to be critical, I’m just not seeing the whole picture
of what you want, and I’m sure the general community is curious as well.
-AlexOn Tue, Apr 29, 2014 at 9:24 AM, Charles Swain wrote:

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.

On 4/29/14, Alex Barry <@Alex_Barry> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which doesn’t
make sense in terms of an open-source product. If you are trying to
build
a different renderer (since you mention OpenGL in use with surfaces), why
not let everyone use it as an optional backend? Also, if you want to use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be used
for. Do you callbacks for pre- and post- function calls for absolutely
all
functions that relate to SDL_Surface? I don’t think you realize that
this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a
specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone.
For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full SDL
community, they may be relying on the person suggesting the change to try
writing a patch rather than making an open suggestion for someone else to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain wrote:

Just realized that there is a better way to describe possible use cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Charles_Swain]

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Like stated, if we switched to callbacks in surfaces we could abstract
how we handle the surface and pixel data. It’s re-merging surfaces
and textures in a dynamically replaceable, modifiable, extensible, and
compatible way. Surfaces are images. The callbacks are fronts to how
the image is handled. We establish the means of inter-working between
callbacks, the original API, and 2.x user code.

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up. Also, callbacks would not interfere with older code
that does this. It would be perfectly acceptable and compatible to do
what you described while callbacks are implemented. Also, I think
most people use SDL not because it is low level (which it isn’t) but
because it is a great abstraction to the boatloads of OS and
implementation (think pixel formats) specific stuff.On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

Your example probably doesn’t really have much use to people, since they
will write their own wrappers, since user-data may never be allocated the
same for different SDL_Surfaces in the same application. I don’t know that
it’s in the scope of SDL to manage user data - that’s why it’s user data.
What sort of data is being changed on a per-function basis that undermines
your intended usage? It’s possible that you are approaching your software
problem from the wrong direction, which you may want to consider, but
without seeing any code, it’s difficult to say one way or another.

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Sorry, I don’t mean to be critical, I’m just not seeing the whole picture
of what you want, and I’m sure the general community is curious as well.
-Alex

On Tue, Apr 29, 2014 at 9:24 AM, Charles Swain <@Charles_Swain>wrote:

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which
doesn’t
make sense in terms of an open-source product. If you are trying to
build
a different renderer (since you mention OpenGL in use with surfaces),
why
not let everyone use it as an optional backend? Also, if you want to
use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be
used
for. Do you callbacks for pre- and post- function calls for absolutely
all
functions that relate to SDL_Surface? I don’t think you realize that
this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a
specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone.
For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full
SDL
community, they may be relying on the person suggesting the change to
try
writing a patch rather than making an open suggestion for someone else
to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain <@Charles_Swain>wrote:

Just realized that there is a better way to describe possible use
cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Andre_D]

“SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up.”

Low level as far as media libraries goOn Tue, Apr 29, 2014 at 12:08 PM, Charles Swain wrote:

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Like stated, if we switched to callbacks in surfaces we could abstract
how we handle the surface and pixel data. It’s re-merging surfaces
and textures in a dynamically replaceable, modifiable, extensible, and
compatible way. Surfaces are images. The callbacks are fronts to how
the image is handled. We establish the means of inter-working between
callbacks, the original API, and 2.x user code.

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up. Also, callbacks would not interfere with older code
that does this. It would be perfectly acceptable and compatible to do
what you described while callbacks are implemented. Also, I think
most people use SDL not because it is low level (which it isn’t) but
because it is a great abstraction to the boatloads of OS and
implementation (think pixel formats) specific stuff.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

Your example probably doesn’t really have much use to people, since they
will write their own wrappers, since user-data may never be allocated the
same for different SDL_Surfaces in the same application. I don’t know that
it’s in the scope of SDL to manage user data - that’s why it’s user data.
What sort of data is being changed on a per-function basis that undermines
your intended usage? It’s possible that you are approaching your software
problem from the wrong direction, which you may want to consider, but
without seeing any code, it’s difficult to say one way or another.

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Sorry, I don’t mean to be critical, I’m just not seeing the whole picture
of what you want, and I’m sure the general community is curious as well.
-Alex

On Tue, Apr 29, 2014 at 9:24 AM, Charles Swain wrote:

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which
doesn’t
make sense in terms of an open-source product. If you are trying to
build
a different renderer (since you mention OpenGL in use with surfaces),
why
not let everyone use it as an optional backend? Also, if you want to
use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be
used
for. Do you callbacks for pre- and post- function calls for absolutely
all
functions that relate to SDL_Surface? I don’t think you realize that
this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a
specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone.
For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full
SDL
community, they may be relying on the person suggesting the change to
try
writing a patch rather than making an open suggestion for someone else
to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain wrote:

Just realized that there is a better way to describe possible use
cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[icculus]

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

–ryan.

[JonnyD]

I don’t see that the abstraction of surfaces as sole carriers of image data
is useful… If that’s what you mean, then it’s simply semantics and
perhaps less intuitive when considering the performance impact of
operations which may be faster in RAM or faster on the GPU.

Jonny DOn Tue, Apr 29, 2014 at 12:14 PM, Andre D wrote:

“SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up.”

Low level as far as media libraries go

On Tue, Apr 29, 2014 at 12:08 PM, Charles Swain wrote:

Other than user data, what benefit would SDL have to changing to
callbacks

for surfaces?

Like stated, if we switched to callbacks in surfaces we could abstract
how we handle the surface and pixel data. It’s re-merging surfaces
and textures in a dynamically replaceable, modifiable, extensible, and
compatible way. Surfaces are images. The callbacks are fronts to how
the image is handled. We establish the means of inter-working between
callbacks, the original API, and 2.x user code.

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up. Also, callbacks would not interfere with older code
that does this. It would be perfectly acceptable and compatible to do
what you described while callbacks are implemented. Also, I think
most people use SDL not because it is low level (which it isn’t) but
because it is a great abstraction to the boatloads of OS and
implementation (think pixel formats) specific stuff.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

Your example probably doesn’t really have much use to people, since they
will write their own wrappers, since user-data may never be allocated
the

same for different SDL_Surfaces in the same application. I don’t know
that

it’s in the scope of SDL to manage user data - that’s why it’s user
data.

What sort of data is being changed on a per-function basis that
undermines

your intended usage? It’s possible that you are approaching your
software

problem from the wrong direction, which you may want to consider, but
without seeing any code, it’s difficult to say one way or another.

Other than user data, what benefit would SDL have to changing to
callbacks

for surfaces?

Sorry, I don’t mean to be critical, I’m just not seeing the whole
picture

of what you want, and I’m sure the general community is curious as well.
-Alex

On Tue, Apr 29, 2014 at 9:24 AM, Charles Swain wrote:

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which
doesn’t
make sense in terms of an open-source product. If you are trying to
build
a different renderer (since you mention OpenGL in use with surfaces),
why
not let everyone use it as an optional backend? Also, if you want to
use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be
used
for. Do you callbacks for pre- and post- function calls for
absolutely

all

functions that relate to SDL_Surface? I don’t think you realize that
this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a
specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing)
everyone.

For

instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full
SDL
community, they may be relying on the person suggesting the change to
try
writing a patch rather than making an open suggestion for someone
else

to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain wrote:

Just realized that there is a better way to describe possible use
cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By
adding

in calls to these callbacks and corresponding circumstances for
BEFORE

a specific API function performs its desired action and making
continued execution of the API function dependent on the return
value

of the callback (specific values depending on the circumstance can
be

reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from
the

inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making
the

actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[T_Joseph_Carter]

I think “low-level” in this context means “It’s not a C++ OOP class
framework”, since that seems to be the (broken by design) wheel every
single new game developer tries to reinvent.

But my prejudice regarding C++ may be showing there.

JosephOn Tue, Apr 29, 2014 at 12:14:16PM -0400, Andre D wrote:

“SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up.”

Low level as far as media libraries go

On Tue, Apr 29, 2014 at 12:08 PM, Charles Swain wrote:

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Like stated, if we switched to callbacks in surfaces we could abstract
how we handle the surface and pixel data. It’s re-merging surfaces
and textures in a dynamically replaceable, modifiable, extensible, and
compatible way. Surfaces are images. The callbacks are fronts to how
the image is handled. We establish the means of inter-working between
callbacks, the original API, and 2.x user code.

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

SDL isn’t very ‘low level’ at all. It communicates with the OS
specific and standards specific abstractions to the hardware. That is
very high up. Also, callbacks would not interfere with older code
that does this. It would be perfectly acceptable and compatible to do
what you described while callbacks are implemented. Also, I think
most people use SDL not because it is low level (which it isn’t) but
because it is a great abstraction to the boatloads of OS and
implementation (think pixel formats) specific stuff.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

A lot of the idea behind SDL is being low level, meaning most developers
using do create wrapper functions around structs and functions from SDL.

Your example probably doesn’t really have much use to people, since they
will write their own wrappers, since user-data may never be allocated the
same for different SDL_Surfaces in the same application. I don’t know that
it’s in the scope of SDL to manage user data - that’s why it’s user data.
What sort of data is being changed on a per-function basis that undermines
your intended usage? It’s possible that you are approaching your software
problem from the wrong direction, which you may want to consider, but
without seeing any code, it’s difficult to say one way or another.

Other than user data, what benefit would SDL have to changing to callbacks
for surfaces?

Sorry, I don’t mean to be critical, I’m just not seeing the whole picture
of what you want, and I’m sure the general community is curious as well.
-Alex

On Tue, Apr 29, 2014 at 9:24 AM, Charles Swain wrote:

Not per application, unless you mean per API use (callback for a
surface is kept in the surface, different surfaces could have
different callbacks and data).

Also, now that I think of it, there are multiple ways to implement
mixing of total replacement of implementations and simple addition to
the current one using these callbacks (all depending on if we put
current implementations in a callback itself and if we call that when
the actual callbacks ask for it, or if we keep current code where it
is and make a default callback just do nothing, etc).

An example usage follows: say I want to tie my usage of OpenGL
texture objects with SDL’s surfaces, using an SDL surface as the
overall representation of a texture and stuffing the texture name in a
segment pointed to by the userdata field. Problem is, without
callbacks, I would need to create new functions that call SDL’s API
functions just to handle things like creating and destroying the
surface while also handling the userdata field’s contents. In
addition, a call to one of SDL’s API functions for surfaces
independently can undermine my intended usage of these surfaces, not
allocating or unallocating the userdata field’s contents or handling
anything related to it. Per surface callbacks would solve this as
they would be called on creation, removal, and any changes or steps
affecting their state by SDL’s API internally. It would mean that I
can handle the surface and the userdata field in real time as an API
call affecting the surface occurs, potentially changing the behavior
of the API call; it would mean I can ‘transparently’ add stuff to
SDL’s API instead of building new (and probably less complete (for
instance)) things over it.

Code that uses SDL’s surface API would still do so in the same way
(except for surface allocation when a non-default callback is desired,
minor difference there (what if we allow establishing the default
callback to be used later when creating surfaces for just this
case?)), but internally the callbacks would be replacing or adding to
implementations of the API call. Struct fields (except for the new
callback function pointer field) would remain the same and should be
used as expected.

Also, has anyone found a usage for the SDL_Surface struct’s userdata
field without implementing a new API over SDL’s current one? I
haven’t.

On 4/29/14, Alex Barry <alex.barry at gmail.com> wrote:

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which
doesn’t
make sense in terms of an open-source product. If you are trying to
build
a different renderer (since you mention OpenGL in use with surfaces),
why
not let everyone use it as an optional backend? Also, if you want to
use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be
used
for. Do you callbacks for pre- and post- function calls for absolutely
all
functions that relate to SDL_Surface? I don’t think you realize that
this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a
specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone.
For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full
SDL
community, they may be relying on the person suggesting the change to
try
writing a patch rather than making an open suggestion for someone else
to
implement. Good luck

On Tue, Apr 29, 2014 at 8:01 AM, Charles Swain wrote:

Just realized that there is a better way to describe possible use
cases.

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[mr_tawan]

I don’t really get the whole idea. Speaking of callbacks, I thought about things like event handlers (eg. on surface loaded handler, etc.). I couldn’t come up with very useful handlers, btw.

Who does this ‘callback’ benefited from ? API developers ? or the API users ? How does it benefits? What is an example scenario? What would be the tradeoff of implementing this ? And is it possible to implement the same functionality by creating a thin wrapper? (may not be not correct pattern, I guess)

[Jared_Maddox]

Message-ID:
<CAK0i_72U2J6suvbxzM-yHUhw-=gefOfrD1uKDuMevZfyFJq50w at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”

2014-04-28 21:58 GMT+02:00 Charles Swain :

I’ve always thought of the userdata field of the SDL_Surface struct as
wasteful, because I couldn’t think of a proper use for it without
having to implement my own conflicting API for surfaces above SDL’s
(to handle the content of the userdata field, and they were
conflicting because individual usage of SDL’s API with that surface
would undermine the integrity of mine). I also did not want to
implement a new API atop SDL’s that exposed a parent struct to the
pointer to the SDL_Surface struct to user code, because it would
require an entirely new API on my part. Then, while riding home from
school by bus, I thought of callbacks.

We could add a new field to the SDL_Surface struct that contains a
function pointer that is called by SDL’s API and user code at specific
points in execution to yield some behavior.

int (user_callback)(SDL_Surface, Uint32, void*);

The first argument would be a pointer to the corresponding surface.
The second argument would be the circumstance which could be before
freeing the surface in a call to SDL_FreeSurface(), after creating the
surface (with an equivalent function to SDL_CreateRGBSurface() or
SDL_CreateRGBSurfaceFrom() that takes the callback to initialize with
as an argument), before and after blitting or scaling, format changes,
some user code specific thing, etc (it’s whatever you can think of).
The third argument would be a pointer to whatever extra data that is
necessary depending on the circumstance, such as the arguments to the
SDL API function that was called which invoked this function, or
nothing (NULL) if suitable for the circumstance. Return values could
be the same across the board or circumstance specific.

What is the use case for this?

I believe the real answer is “anything non-trivial that uses the
userdata field”.

Can’t immediately think of anthing I would actually want to use that
field for, trivial or otherwise, but none the less (I considered the
posibility of an image-capture interface… but this is a still-image
interface, not a image stream or snap-shot interface).> Date: Mon, 28 Apr 2014 22:08:02 +0200

From: Jonas Kulla
To: SDL Development List
Subject: Re: [SDL] (Proposal) Callbacks for surfaces

Date: Tue, 29 Apr 2014 08:17:12 -0400
From: Alex Barry <alex.barry at gmail.com>
To: SDL Development List
Subject: Re: [SDL] (Proposal) Callbacks for surfaces
Message-ID:
<CAJSO58NFTsw_W9jJcerwPsr1a2p_g7xCKLYo9x8mzBcRDii70A at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”

Not to criticize, but here’s a question; why not just build another
rendering backend for the things that don’t exist?

The reason I say that is you are basically asking for the ability to
override the default renderers on a per-application basis, which doesn’t
make sense in terms of an open-source product. If you are trying to build
a different renderer (since you mention OpenGL in use with surfaces), why
not let everyone use it as an optional backend? Also, if you want to use
SDL_Surface and OpenGL together, why not just use a SDL_Renderer?

Also, you need to be more specific on what the callback(s?) would be used
for. Do you callbacks for pre- and post- function calls for absolutely all
functions that relate to SDL_Surface? I don’t think you realize that this
means a lot of refactoring in the code, especially if all SDL_Surface
functions need to only function if the callback function returns a specific
value.

For improving your use-case some more, trying describing a specific
situation, rather than generalizing (and possibly confusing) everyone. For
instance, you mention “BEFORE a specific API function…” - which API
functions, and why do they need callbacks like you describe?

I’m curious about what you mean, but if it is acceptable to the full SDL
community, they may be relying on the person suggesting the change to try
writing a patch rather than making an open suggestion for someone else to
implement. Good luck

A software shaders system could probably use it for hook points… but
I’m not certain that it would make sense.

Date: Tue, 29 Apr 2014 12:18:34 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] (Proposal) Callbacks for surfaces
Message-ID: <535FD0DA.8040004 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Everything that could be done with a surface. This includes the
functionality provided by SDL’s current API, and much more. By adding
in calls to these callbacks and corresponding circumstances for BEFORE
a specific API function performs its desired action and making
continued execution of the API function dependent on the return value
of the callback (specific values depending on the circumstance can be
reserved for indicating that some section or step or most of the
function is to be skipped because the callback already handled it or
wants it ignored), SDL’s API’s implementation can be replaced from the
inside by things such as another software renderer or hardware
accelerated rendering such as OpenGL. In fact, we could move the
implementation of SDL’s current API’s internals into a callback,
changing the current API functions into front ends for standardized
callback calls. You could even string multiple callback functions
together, if their implementations are non-conflicting, by making the
actual callback call the other callbacks (after it swaps the current
user-data pointer with a callback specific pointer as necessary,
keeping the pointers between callback calls in a struct or segment
pointed to by the user-data field).

http://www.anbg.gov.au/images/flags/signal/n.gif

–ryan.

If that was a “no” (or a “yes”, or a “start your engines”), then it
would be a lot better actually spelled out.

[icculus]

http://www.anbg.gov.au/images/flags/signal/n.gif

If that was a “no” (or a “yes”, or a “start your engines”), then it
would be a lot better actually spelled out.

It was a no.

(But thank you for looking it up. )

–ryan.

[Jared_Maddox]

Message-ID: <53632F62.9000005 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

http://www.anbg.gov.au/images/flags/signal/n.gif

If that was a “no” (or a “yes”, or a “start your engines”), then it
would be a lot better actually spelled out.

It was a no.

(But thank you for looking it up. )

What gave that away, “start your engines”?

At any rate, I hope this is enough to conclude the proposal. No sense
adding things that the primary maintainers/contributors oppose.> Date: Fri, 02 May 2014 01:38:42 -0400

From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] (Proposal) Callbacks for surfaces

[Nathaniel_J_Fries]

I can not perceive a use for this beyond implementing custom renderers, which could be implemented in a much simpler and more direct way.

On the topic of software shaders; however, I think a 2D shader API would be a nice extension of the Render API, but implementing it would really strain the scope of SDL.------------------------
Nate Fries

[Jared_Maddox]

Message-ID: <1399240638.m2f.43335 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

On the topic of software shaders; however, I think a 2D shader API would be a nice extension
of the Render API, but implementing it would really strain the scope of SDL.

I’m the one that mentioned it, and I absolutely think it’s beyond the
appropriate scope of SDL.> Date: Sun, 04 May 2014 21:57:18 +0000

From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] (Proposal) Callbacks for surfaces

[JonnyD]

That’s why SDL_gpu exists. I think a lot of good stuff is out of scope for
SDL, shaders included. I wouldn’t mind help getting SDL_gpu developed
further.

Jonny DOn Tue, May 6, 2014 at 3:08 AM, Jared Maddox wrote:

Date: Sun, 04 May 2014 21:57:18 +0000
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] (Proposal) Callbacks for surfaces
Message-ID: <1399240638.m2f.43335 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

On the topic of software shaders; however, I think a 2D shader API would
be a nice extension
of the Render API, but implementing it would really strain the scope of
SDL.

I’m the one that mentioned it, and I absolutely think it’s beyond the
appropriate scope of SDL.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org