Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Servers could send arbitrary metadata with each frame #29

Open
rsodre opened this issue Nov 6, 2015 · 6 comments
Open

Servers could send arbitrary metadata with each frame #29

rsodre opened this issue Nov 6, 2015 · 6 comments

Comments

@rsodre
Copy link
Contributor

rsodre commented Nov 6, 2015

Information could be shared between applications thru the stablished Syphon connection.
Using a NSDictionary would leave the server and client open to share anything.
As an example, render time, document name, color correction, name of a complementary Syphon texture.

@bangnoise
Copy link
Member

We have thought about this.

The main obstacle is that (by design) there is no concept of frames as individual entities, just a single surface with changing content. There is no way to tie metadata to a single frame because the content can change at any time. This might still be useful for less transient information.

@bangnoise bangnoise changed the title Servers could send an arbitrary NSDictionary with each frame Servers could send arbitrary metadata with each frame Jan 3, 2023
@maybites
Copy link

maybites commented Jan 4, 2023

to continue the discussion from #82:

This is what spout says about its own implementation: frameBufferSharing

But I understand now it might be tricky to implement it in a water thight manner.

@bangnoise
Copy link
Member

@maybites we specifically don't want to block server and client processes in the way Spout does.

@vade
Copy link
Member

vade commented Jan 4, 2023

To chime in, I think this can be revisited if we decide to tackle internally pooling IOSurfaces, which would allow us to vend unique surfaces per frame (though they would have re-used addresses), and potentially associate user low cost user data dictionary along with it. I dont want to promise anything we can't deliver, but its worth mentioning.

@vade
Copy link
Member

vade commented Jan 4, 2023

for reference :

/* These calls let you attach property list types to a IOSurface buffer.  These calls are 
   expensive (they essentially must serialize the data into the kernel) and thus should be avoided whenever
   possible.   Note:  These functions can not be used to change the underlying surface properties. */
- (void)setAttachment:(id)anObject forKey:(NSString *)key;
- (nullable id)attachmentForKey:(NSString *)key;
- (void)removeAttachmentForKey:(NSString *)key;
- (void)setAllAttachments:(NSDictionary<NSString *, id> *)dict;
- (nullable NSDictionary<NSString *, id> *)allAttachments;
- (void)removeAllAttachments;

@maybites
Copy link

maybites commented Jan 5, 2023

@bangnoise

we specifically don't want to block server and client processes in the way Spout does.

Oh, I get that. I wouldn't advocate it, I just added that link for reference.

But I am glad to hear you considering this feature seriously and see the potential benefit of it. A low cost user data dictionary would be the way to go. Thats what I am doing with spout, serialized to and from a byte buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants