669923 - When I zoom a video, the controls get fuzzy

Status: NEW

(Toolkit :: Video/Audio Controls, defect)

Description

[Benjamin Smedberg]

I frequently zoom videos (airmozilla) so that they are not quite so tiny on-screen, but this has the rather odd effect of making the video controls fuzzy because they are sampled up images.

I wonder if we can write the controls in SVG instead?

Comment 1

[cajbir (:cajbir)]

They were originally written in SVG so it's certainly possible.

Comment 2

[Paul Adenot (:padenot)]

I've got a working patch for some of the controls, to replace png by svg, but I was wondering if it would be necessary to provide a png fallback ? Can a user compile without/disable svg ?

Comment 3

[Timothy B. Terriberry (:derf)]

There's an svg.enabled property, but I don't believe you can compile without SVG support entirely. I'm not sure how much the property actually turns off.

Comment 4

[Paul Adenot (:padenot)]

WIP : http://paul.cx/svg-controls/

I will now integrate the svg images in the UI.

Note that the throbbler can be animated using an <animateTransform> element, or plain old javascript. The former is quite slow in comparison of the former, and I fail to understand why.

Comment 5

[Paul Adenot (:padenot)]

Attachment: Patch v0 -- Replace png by svg for audio/video controls.

Here is a patch that adds the svg images.

I notice that the SVG are correctly rendered in about 1 zoom step on 4, which is quite problematic. Is it normal or should I file a bug ? I haven't found any related bug so far.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> WIP : http://paul.cx/svg-controls/
> Note that the throbbler can be animated using an <animateTransform> element,
> or plain old javascript. The former is quite slow in comparison of the
> former, and I fail to understand why.

I took a look at the commented-out animateTransform code in your WIP linked above -- it indeed has dead-time at the end of every cycle, which is what I assume you're talking about RE "slow".

That's because you only specify keyFrames for 80% of the way through the animation cycle. (the last one is at 0.8 -- note that that's in units of normalized animation-duration, *not* in units of seconds)  So your final keyFrame lasts for the final 20% of the animation.

You want to change your keyTimes values to range from 0 to 1 -- in particular, these values should work (they do on my system):
  keyTimes="0.0; 0.125; 0.25; 0.375; 0.5; 0.625; 0.75; 0.875; 1.0"

Comment 7

[Daniel Holbert [:dholbert]]

(having said that -- if you do actually hit perf issues on this animation (I don't), it is the case that transform computations are a bit expensive when compared to other types of animations.  You might get improved performance by using a non-rotating circle, with the 8 separate opacity animations to animate each dot separately.  Probably not necessary, but something to consider.)

Comment 8

[Paul Adenot (:padenot)]

Daniel, thank you for pointing that mistake out.

By slow, I meant that it uses quite a lot of CPU. On my Linux laptop, it eats about 30% of on core on my machine, with visible pauses in the animation. The js version uses 4% of one core, and is perfectly fluid. On my Windows box, the animate version uses about ten times more CPU than the js version.

I'll tinker with the idea you mention, but seems not as straightforward as vectoring the png and applying a rotation, but I agree a declarative solution seems nicer that a js solution.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #8)
> By slow, I meant that it uses quite a lot of CPU. On my Linux laptop, it
> eats about 30% of on core on my machine, with visible pauses in the
> animation.

Gotcha - in that case, you will likely get better performance from a non-transform-dependent animation.  Our SMIL code hasn't really been optimized, so I can't guarantee that my opacity-animation suggestion will make it as fast as the animated PNG, but it should be better than the <animateTransform> version.

> I agree a declarative solution seems nicer that a js solution.

Yup -- the other issue with the JS solution is that it won't work if you're using the SVG as an image (which I assume you will be).  (We disable scripts inside of svg-as-an-image, for security reasons.)

Comment 10

[Paul Adenot (:padenot)]

> Yup -- the other issue with the JS solution is that it won't work if you're 
> using the SVG as an image (which I assume you will be).  (We disable scripts 
> inside of svg-as-an-image, for security reasons.)

Indeed, those images will be used as background image  via CSS (and that's why it depends on bug 600207), so a JS solution wouldn't work.

The other solution would be to use the SVG code in an XBL binding (I suppose we could use JS in that case), and to use -moz-binding to display it using CSS, but I can't make the SVG to refresh dynamically when zooming, I have to drag my mouse over the SVG image for it to resize after having zoomed.

Comment 11

[Robert Longson [:longsonr]]

(In reply to comment #3)
> There's an svg.enabled property, but I don't believe you can compile without
> SVG support entirely. I'm not sure how much the property actually turns off.

The svg.enabled property was removed some time ago.

Comment 12

[Justin Dolske [:Dolske]]

We looked at doing SVG some time ago (before svg-in-img was supported), and it was a headache to use. I think it's acceptable to use SVG just for the image pieces, though, and continue to use XUL/HTML for the general framework of things.

CC'ing shorlander here... We want to update/refresh the videocontrols' appearance soon... Any opinions on the pros/cons of doing that with SVG?

Also, at some point we'll probably revisit how zoom + the controls should work -- but that's another bug for sure. :)

Comment 13

[Stephen Horlander [:shorlander]]

(In reply to comment #12)
> CC'ing shorlander here... We want to update/refresh the videocontrols'
> appearance soon... Any opinions on the pros/cons of doing that with SVG?

There are a few problems I keep running into with SVG. It is much harder to get pixel perfect designs with SVG. Usually this ends up requiring a lot of complicated paths, masks and many filters. This also results in much higher maintenance for updating and changing images.

The scaling benefit is nice. However it doesn't always look good except at certain zoom percentages.

Another potential benefit to SVG that could make up for the increased complexity would be separating the paths from the gradients and filters. For instance you could have a bunch of basic shapes and paths in one file and just call the right fills and filters with CSS and magically have the right style.

It is kind of a tough call on which is ultimately the better approach. The video controls might be a good place to experiment with it though.

Comment 14

[Paul Adenot (:padenot)]

> The scaling benefit is nice. However it doesn't always look good except at 
> certain zoom percentages.

This is (I suppose) bug 600207, and thus SVG should look nice at any zoom level in a future (as in all the other browser supporting SVG and all the image viewer I know).

Comment 15

[Paul Adenot (:padenot)]

I don't plan to work on this in the near future.