Re: Support for 32bit on OS X and testing infrastructure
Robert Strong wrote on 09/22/2014 09:50 AM: I see. So I will investigate what's necessary to get those builds running in parallel via Mozmill CI. Specifically, the 32bit plugin-container and libraries that it loads. The one and only plugin we make use of for tests is Adobe Flash. There is no other plugin we currently test with Mozmill. So by enabling tests for 32bit builds, those tests will also run. -- Henrik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
Robert Strong wrote on 09/22/2014 11:07 AM: Hi Robert, All of the major changes for Mac v2 signing have landed on the Oak branch. This will allow us to test installing and updating before landing on mozilla-central. [..] If no serious issues are found we are hoping to be able to land on mozilla-central later this week. Thanks a lot for this update. In case of our Mozmill update tests, those have been updated yesterday for Nightly to be able to handle the new signed builds. If all goes well with updates today, I will backport my patch on bug 1063584 to Aurora today. There are only two issues left for the mozmill-automation package, which I hopefully can finish up by today or tomorrow. https://github.com/mozilla/mozmill-automation/milestones/2.0.8.1 That means we should then be able to run our update tests against builds of the oak tree, which should give an extra bit of safety. Cheers, -- Henrik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: image-rendering: pixelated CSS property-value
Summary: The CSS declaration image-rendering: pixelated allows authors to request that we scale up images by effectively making the pixels larger (using a nearest-neighbor algorithm). This is in contrast to the default (non-pixelated) scaling behavior, which tends to blur the edges between an image's pixels when upscaling. The default behavior is appropriate for use-cases like photos, but authors may prefer a pixelated look e.g. when scaling up pixel-art or favicons. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=856337 Link to standard: http://dev.w3.org/csswg/css-images/#valuedef-pixelated Platform coverage: All Estimated or target release: Firefox 35 or 36 Preference behind which this will be implemented: None. This is a small, targeted feature; if we need to disable it for some reason, we can easily do so with a small change to the CSS parser (just removing the new keyword from the keyword-table for this property). NOTES: - Blink has already implemented pixelated[1] and it'll be shipping[2] in Chrome 38 [3]. So, if when we ship it, there will be interoperability between at least 2 engines here. (Other rendering engines expose similar behavior, albeit under different non-standard keyword-names.) - Gecko already has image-rendering: -moz-crisp-edges as a way to request this behavior; the difference is that -moz-crisp-edges uses the same algorithm (nearest-neighbor) regardless of whether it's upscaling or downscaling, whereas pixelated is supposed to *only* use that algorithm for upscaling, and use the default (auto) behavior when downscaling. ~Daniel [1] Blink intent-to-implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Q8N6FoeoPXI [2] Blink intent-to-ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zSasd2LL8Mc [3] http://blog.chromium.org/2014/08/chrome-38-beta-new-primitives-for-next.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 2014-09-23, 4:53 PM, Daniel Holbert wrote: NOTES: - Blink has already implemented pixelated[1] and it'll be shipping[2] in Chrome 38 [3]. So, if when we ship it, there will be interoperability between at least 2 engines here. (Other rendering engines expose similar behavior, albeit under different non-standard keyword-names.) - Gecko already has image-rendering: -moz-crisp-edges as a way to request this behavior; the difference is that -moz-crisp-edges uses the same algorithm (nearest-neighbor) regardless of whether it's upscaling or downscaling, whereas pixelated is supposed to *only* use that algorithm for upscaling, and use the default (auto) behavior when downscaling. Why are upscaling and downscaling treated differently for pixelated? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 02:16 PM, Ehsan Akhgari wrote: Why are upscaling and downscaling treated differently for pixelated? I'm not entirely sure what the origin of that distinction is, but my understanding (mostly from reading Tab's comments/responses on the Blink intent-to-implement thread) is that Nearest-Neighbor Scaling really doesn't look pixelated at all when scaling down, so authors asking for a pixelated look really don't want nearest-neighbor downscaling. The default scaling algorithm will do a better job of downscaling your image in a non-datalossy-way than nearest-neighbor would. ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 02:39 PM, Daniel Holbert wrote: On 09/23/2014 02:16 PM, Ehsan Akhgari wrote: Why are upscaling and downscaling treated differently for pixelated? I'm not entirely sure what the origin of that distinction is, but my understanding (mostly from reading Tab's comments/responses on the Blink intent-to-implement thread) is that Nearest-Neighbor Scaling really doesn't look pixelated at all when scaling down FWIW, I also emailed www-style to sanity-check my understanding to see if there are any other reasons for this behavior-difference: http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 02:56 PM, Daniel Holbert wrote: FWIW, I also emailed www-style to sanity-check my understanding to see if there are any other reasons for this behavior-difference: http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html Turns out there wasn't a strong reason for the difference; Tab's now updated the ED to remove the requirement that we match auto when downscaling. This makes the implementation considerably simpler, which is great. It also means that pixelated will essentially just be a more-interoperable version of -moz-crisp-edges, for the time being. (Down the line, we might want to change crisp-edges to use a different scaling algorithm, and then they wouldn't be aliases anymore. The spec allows us flexibility in choice of algorithm for crisp-edges [and there are other edge-preserving algorithms like hqx that could be better]. pixelated is required to stick with nearest-neighbor, though.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On Tue, Sep 23, 2014 at 4:07 PM, Daniel Holbert dholb...@mozilla.com wrote: On 09/23/2014 02:56 PM, Daniel Holbert wrote: FWIW, I also emailed www-style to sanity-check my understanding to see if there are any other reasons for this behavior-difference: http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html Turns out there wasn't a strong reason for the difference; Tab's now updated the ED to remove the requirement that we match auto when downscaling. This makes the implementation considerably simpler, which is great. It also means that pixelated will essentially just be a more-interoperable version of -moz-crisp-edges, for the time being. Would it make sense to have separate properties for scale up and scale down? With image-rendering being a shorthand for setting both? Separately, isn't image-rendering a bit too generic of a name for setting scaling strategy? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 24/09/14 09:24, Jonas Sicking wrote: Would it make sense to have separate properties for scale up and scale down? With image-rendering being a shorthand for setting both? Separately, isn't image-rendering a bit too generic of a name for setting scaling strategy? I guess it was chosen because we already have an image-rendering property from SVG to control how raster images are scaled/rendered (although it was always more of a hint, rather than this new value which would be required behaviour). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 04:24 PM, Jonas Sicking wrote: Would it make sense to have separate properties for scale up and scale down? With image-rendering being a shorthand for setting both? Firstly: per my replies on the subthread started by ehsan, the distinction in scale up vs. scale down behavior has (just now!) been removed from the spec. It turns out that it was a somewhat arbitrary choice. I suspect that removes the motivation for your question, but just in case it doesn't: I don't think see a strong use-case for an author to request specific different scale-up vs. scale-down behaviors -- particularly given that there are only a few image-rendering options anyway, and only one of them (pixelated) is specced with actually-reliable results. (The others are basically whatever-the-rendering-engine-wants-to-do, under these rough guidelines.) If an author really wants different behavior for scaling up vs. scaling down, they can already get their desired result via media queries and/or JS. Separately, isn't image-rendering a bit too generic of a name for setting scaling strategy? Perhaps, but that ship has sailed :) This property was originally part of SVG, and there, I think the scaling aspect was just implied. :) (since it's already in the SVG name) If it didn't already exist in SVG, and the CSSWG were creating this property from scratch, they probably would have picked a different name that included some mention of scaling; but here we are. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 04:38 PM, Daniel Holbert wrote: On 09/23/2014 04:24 PM, Jonas Sicking wrote: Would it make sense to have separate properties for scale up and scale down? With image-rendering being a shorthand for setting both? Firstly: per my replies on the subthread started by ehsan (Oh, I guess you were *responding* to that subthread :) I didn't initially see that, since I hadn't yet bumped this to my threaded dev.platform folder. Anyway, I don't see a compelling motivation to go for separate downscaling vs. upscaling prefs separately, at this point. It's possible the property could be split in the future, though.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 9/23/14 4:24 PM, Jonas Sicking wrote: This makes the implementation considerably simpler, which is great. It also means that pixelated will essentially just be a more-interoperable version of -moz-crisp-edges, for the time being. Would it make sense to have separate properties for scale up and scale down? With image-rendering being a shorthand for setting both? Maybe. We use this property in Firefox's UI, to make favicons look better when upscaling on hidpi displays... NN upscaling looks better for tiny icons, because smooth algorithms just make them look blurry. I noted in bug 839923 comment 0 that it's not ideal to have the same behavior for downscaling, and the issue tangentially came up again in bug 1041845. So there's a plausible use case. OTOH, scaling tiny icons is just generally not good with either algorithm, so having the capability isn't really of much use. There are other scaling algorithms explicitly designed to scale small/pixel-art images much better, but AFAIK no browser actually implements such a thing. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee cat...@mozilla.com wrote: Just a short note to say that this experiment is now live on mozilla-inbound. ___ dev-tree-management mailing list dev-tree-managem...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tree-management What was the outcome? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: resource timing
As of next week we intend to turn on resource timing. It has been developed behind the dom.enable_resource_timing pref. == Summary == The Resource Timing API allows web applications to access timing information for resources in a document. == Platform Coverage == Resource timing works on all platforms. An issue tracked in bug 1064706 is that in e10s the performance.getEntries() will return an empty array. == Test coverage == dom/tests/mochitest/general/test_resource_timing.html dom/tests/mochitest/general/test_resource_timing_cross_origin.html There is also the w3c test, which presents some failures for all UAs because of bugs in the test. http://w3c-test.org/resource-timing/test_resource_timing.html == Interop == Chrome and Opera have prefixed the webkitClearResourceTimings and webkitSetResourceTimingBufferSize methods, and the onwebkitresourcetimingbufferfull event handler. == Links == http://www.w3.org/TR/resource-timing/ https://bugzilla.mozilla.org/show_bug.cgi?id=1002855 Thanks -- Valentin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: resource timing
Awesome work guys. Thanks! On Tuesday, September 23, 2014 6:11:58 PM UTC-7, Valentin Gosu wrote: As of next week we intend to turn on resource timing. It has been developed behind the dom.enable_resource_timing pref. == Summary == The Resource Timing API allows web applications to access timing information for resources in a document. == Platform Coverage == Resource timing works on all platforms. An issue tracked in bug 1064706 is that in e10s the performance.getEntries() will return an empty array. == Test coverage == dom/tests/mochitest/general/test_resource_timing.html dom/tests/mochitest/general/test_resource_timing_cross_origin.html There is also the w3c test, which presents some failures for all UAs because of bugs in the test. http://w3c-test.org/resource-timing/test_resource_timing.html == Interop == Chrome and Opera have prefixed the webkitClearResourceTimings and webkitSetResourceTimingBufferSize methods, and the onwebkitresourcetimingbufferfull event handler. == Links == http://www.w3.org/TR/resource-timing/ https://bugzilla.mozilla.org/show_bug.cgi?id=1002855 Thanks -- Valentin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 2014-09-23, at 13:53, Daniel Holbert dholb...@mozilla.com wrote: Link to standard: http://dev.w3.org/csswg/css-images/#valuedef-pixelated Reading the spec it doesn’t say anything about what to do when the image is scaled up on one axis and down on the other. It’s probably not a particularly valid use case, but I’d expect there to be at least something on the subject. The image sizing examples in the same document actually demonstrate this exact case, odd as it might seem. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 10:08 PM, Martin Thomson wrote: On 2014-09-23, at 13:53, Daniel Holbert dholb...@mozilla.com wrote: Link to standard: http://dev.w3.org/csswg/css-images/#valuedef-pixelated Reading the spec it doesn’t say anything about what to do when the image is scaled up on one axis and down on the other. It’s probably not a particularly valid use case, but I’d expect there to be at least something on the subject. The image sizing examples in the same document actually demonstrate this exact case, odd as it might seem. Yup, good question. So, three late-breaking updates from ~today that address this: 1) Tab moved this property-value to the CSS Images Level 3 spec in the last day or so, so I believe the canonical definition is now here: http://dev.w3.org/csswg/css-images-3/#valdef-image-rendering-pixelated (This is a *slightly* different URL than the one I gave in my initial intent to implement post -- note the -3 in css-images-3. Sorry for the confusion.) 2) I posted to www-style asking basically your exact question earlier today (following up on a thread from Simon Sapin), and Tab accepted Simon's proposal to relax the language make it only care if at least one axis is being upscaled, and otherwise do the auto behavior. 3) Later on today, in response to ehsan's question on this thread, I asked if there was any strong reason to have the upscaling/downscaling behavior-difference in the first place; there was not, so the distinction was removed altogether. So the current spec text is simply: # pixelated #The image must be scaled with the # nearest neighbor or similar algorithm, # to preserve a pixelated look as the image # changes in size. from here: http://dev.w3.org/csswg/css-images-3/#valdef-image-rendering-pixelated Thanks, ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 01:53 PM, Daniel Holbert wrote: Link to standard: http://dev.w3.org/csswg/css-images/#valuedef-pixelated As noted elsethread (in my response to Martin), it looks like the canonical definition of this property-value is actually in a different ED -- the level 3 ED. (whereas the link above is currently the level 4 ED). The corrected link is: http://dev.w3.org/csswg/css-images-3/#valdef-image-rendering-pixelated (Both versions have spec-text on this property-value, and until this morning, I believe the spec-text was the same; but there have been a few small changes in response to my questions on www-style today, and those changes have happened in the corrected URL for the level-3 spec -- not the URL I'd originally posted for the level-4 spec.) Thanks, sorry for any confusion caused by this. ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/23/2014 10:30 PM, Daniel Holbert wrote: As noted elsethread (in my response to Martin), it looks like the canonical definition of this property-value is actually in a different ED -- the level 3 ED. (whereas the link above is currently the level 4 ED). (This change -- moving the image-rendering property between spec-levels -- only happened yesterday[1] which is why I hadn't noticed it until after sending my intent-to-implement post.) [1] http://lists.w3.org/Archives/Public/www-style/2014Sep/0301.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
