Nasty hack

[Samsy]

Nasty hack

[spite]

You say it like the rest of the library isn't a bunch of hacks of prototypes and host methods.

If you understand the purpose of the library, it makes sense to hijack all methods that can be used to sync animations. There's no good reason to have a video that runs in real-time in a non-realtime capturing session.

The only real issue is that all of those methods should be hijacked based on a configuration provided by the user, instead of blindly. You might want requestAnimationFrame to be throttled, but need setTimeout to jumpstart the animation. That, for instance, is a known issue that needs manual stepping from the console.

In the future I plan to add a configuration object to control what is intercepted and what's not, but still will require the developers to know what they're doing and what the library can do.

If you don't want non-realtime capture (or rather, want real-time capture), just use CaptureStream and MediaRecorder.

[Samsy]

This library is awesome for what it is doing, and we are using it for a production side as a gif generator, and thank you for this.
I just trigger the fact there might be another way than overriding, and that way it could help people using this in higher scale, no offense

[spite]

None taken, don't worry! I should have sprinkled more emojis in the reply, but i was in a rush. I'm the first one to recognise it's all a bunch of hacks, but that's they only way i can see it working, since ideally it should be completely transparent to the page.

I'm the first to not be happy with the way timeouts and HTMLVideo and Audio Elements currentTime are being set (since, for instance, there's no way to setting them back to their original state).

As I said, the idea is to provide a configuration mask to enable what values and methods to intercept -and more things, like setting the canvases correctly to support transparency-, but I haven't had time to address those issues.

[jay-hennen]

Can you explain why there's so much time-related monkey-patching going on at such a low level? I really want to use CCapture for my project but overriding Date.now is a dealbreaker since it breaks moment, Cesium, and probably a bunch of other things. Am I missing some key encapsulation step that stops the overrides from breaking tons of other libraries?

I'm a bit of a javascript novice so I'm trying to figure out why the overriding is done from a design perspective.

[spite]

I think you're confused about what's the purpose of this library: it's capturing framerate-independent animations.

If you want to capture at 60 FPS, but your animation + capturing overhead takes more than 16.66 ms ( 1000 ms / 60 ), then your final animation will be choppy --- it's the equivalent of dropping frames when transcoding. Ccapture helps getting 60, 120, 100000 FPS animations, but it does it by hooking functions that are used for time syncing.

If you don't mind dropping frames, just use HTMLCanvasElement.captureStream

[jay-hennen]

Now I think I get the purpose of the library, but I still don't quite understand why it needs to hook such fundamental functions. Are the alternatives just that complicated?

The two big things I discovered specifically about hooking those functions was it caused several Cesium components related to moving the camera around to exhibit weird behavior (camera would 'glide' forever in the direction panned), and also broke the ability for moment to parse time strings correctly. That's why I asked about some way to encapsulate the behavior that I was unaware of.

In my scenario, what attracts me to CCapture is the API and the paradigm implied by 'capturer.capture(canvas)' in particular. The app is a client-rendered view of a server-side simulation, using Cesium on the client. The Cesium canvas is drawn at 30 fps, and the user can move smoothly around the map, but the simulation is usually much lower than 30fps. So for recording here the strategy here is to only capture a frame when the simulation steps, and then stitch that into an animation at the desired fps. In our case, dropping frames when the user is panning the camera for example is acceptable. Also of interest is getting all those frames exported in a zip/tar/webm/mpeg(?). I realize all these things could be accomplished with smaller libraries (such as gif.js, which I'm actively researching), but right now I'm still learning what's out there. CCapture's API made it seem like I could do all those things with a single library.

[jay-hennen]

Forgot to point this out too: Commenting out all the code that hooks the time functions let me use CCapture (for gifs, anyway) exactly as I hoped I could. Even if making each specific hook optional through settings is too difficult, making it an all-or-nothing choice still might have value.

[spite]

Yes, that's the idea. Given that some people want to use it without it affecting HTMLVideoElement/HTMLAudioElement, and some people need those elements to be hooked, the best option is to make it configurable. That also helps with the planned Web Extension.

It's coming...