You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently all textures passed are GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA. We could support other types and formats.
Perhaps
when creating a server, one can optionally specify the format and type for the frames you're serving. This will default to float RGBA.
when creating a client, you can optionally specify the format and type you are interested in receiving. This request may or may not be honoured. This will default to GL_UNSIGNED_INT_8888_REV RGBA.
Internally, the backing chosen will be the "highest" values for format and type requested by any clients, but never a higher value than that set by the server. Consequently in a situation with multiple clients the backing may change during the lifetime of the clients (but only for the better quality-wise). If none of the optional attributes are present, behaviour will be exactly as now.
my current thinking is that clients should transmit their capabilities to servers when they join, and servers should scale down their backing if a client can't deal with what it has selected. Cases where that scaling down would happen should be rare as any sanely-created contexts are going to match capabilities on the same machine
The text was updated successfully, but these errors were encountered:
vade
changed the title
Syphon could support textures in formats other than GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV
Float Support: IE: Syphon could support textures in formats other than GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV
Dec 30, 2022
From google code:
Currently all textures passed are GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA. We could support other types and formats.
Perhaps
Internally, the backing chosen will be the "highest" values for format and type requested by any clients, but never a higher value than that set by the server. Consequently in a situation with multiple clients the backing may change during the lifetime of the clients (but only for the better quality-wise). If none of the optional attributes are present, behaviour will be exactly as now.
my current thinking is that clients should transmit their capabilities to servers when they join, and servers should scale down their backing if a client can't deal with what it has selected. Cases where that scaling down would happen should be rare as any sanely-created contexts are going to match capabilities on the same machine
The text was updated successfully, but these errors were encountered: