What exactly does fitFrame() do, and why does it need to modify the publicly accessible transform? I assume the position/scale given by the user defines the "frame" we want the movie to fit in, so it seems like it wouldn't make any sense to modify that. If there are internal transformations going on to decode the video or something (I have no idea how videos work) then shouldn't those be private sf::Transforms, separate from the one the public setters/getters access?
tl;dr I think we need to know a bit more about the problem.
Given a sf::Rect (origin + size), it resizes and positions the movie so that it best fits that rect. For example, given a target rect of (0, 0, 400, 300) and a movie whose size is (200, 100), the movie will be positioned at (0, 50) with a size of (400, 200). Like in the attached image.
The user could indeed set the position / scale himself but it is not that simple because you have to take into account the aspect ratio of the movie and the aspect ratio of the target frame. So I wanted to provide an easy way for that.
Actually this is not related to decoding, only presentation
What I meant with LSP is, does every single operation of sf::Transformable make sense for the Movie class?
Yes they do, although not each of them is as much useful.
By the way, have you considered splitting this class into a resource and a graphical representation, similar to sf::Texture and sf::Sprite? It may not be too useful to have multiple graphical representations because of streaming, but still I'd reflect about this approach.
No, not yet. The most relevant use case would be to replace animated sprites but I don't know how much of an interest it is compared to classical animation systems with sprite sheets. Or maybe it comes of interest with high resolution + high framerate animations?
To be honest, 3 layers of class hierarchy to achieve something simple is far from clean to me 
Yes I went a bit quick to the conclusion
and the more I think of this solution, the more it looks like to a hidden way of doing the logic in Movie without saying it.
If you want to preserve sf::Transformable in your front-end Movie class as well as the possibility that the user sets attributes that directly affect the back-end MovieImpl, you won't get around querying Movie from MovieImpl whenever you need updated information. The simplest way would be passing a sf::Transformable& reference to MovieImpl.
This looks like a really great idea!!! I guess you've made me happy for the whole day
In particular, do any of the rotation methods of sf::Transformable make sense on an sfe::Movie? Do you plan on supporting arbitrary video rotations? (is that even possible?)
Why not? What I'm seeing is that I'll need more work to get a subset of the transformations working rather than just fully supporting sf::Transformable.
For the record, as someone who will probably use sfe::Movie someday (whenever I have time to code again...) I would be perfectly fine with a Movie class that's Drawable but not Transformable, and instead takes an IntRect in a method like resizeToFrame().
Noted!
