Re: Intent to implement: "image-rendering: pixelated" CSS property-value
On 09/24/2014 09:23 PM, Daniel Holbert wrote: > So, it's not required to behave exactly the same everywhere; it simply > codifies an author's intent. (OK, I suppose it *is* required to behave > exactly the same everywhere in the case of "pixelated" & upscaling, > since that requires a particular algorithm, to achieve a particular > effect. But other than that, it's purely a hint.) (And actually, even in the case of pixelated & upscaling, the spec just requires "nearest-neighbor _or similar_". So, [as it goes on to say], the spec "does not dictate any particular scaling algorithm to be used.") ___ 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/24/2014 06:26 PM, Ehsan Akhgari wrote: > Hmm, doesn't that basically allow non-interoperable implementations? :( > I think Jonas' idea on having separate properties for the upscale vs. > downscale cases is much better. I'm unconvinced about the usefulness of exposing that much control. This is something that could be added to CSS Images level 4, though, if you really thing it merits doing. I suspect CSS Images level 3 is too late in the game for that sort of change. > So, what's Chrome's position with regards to this spec churn? As of this morning, their "intent to ship" thread had a few posts sounding like they'd take out the smart-downscaling eventually, to align with the ED as-it-stood-this-morning. But now that prettier downscaling is allowed, I assume they'll stick with what they've already implemented (which includes the default downscaling behavior). > Is what > they're going to ship in Chrome 38 going to be interoperable with our > implementation? It depends on what you mean by "interoperable". If you're asking if they'll produce the exact same result, pixel-for-pixel, when downscaling an image, then no. But that's likely already the case, with the default scaling behavior; I'd be surprised if we matched them 100% on image-downscaling. Also, stepping back a bit w.r.t. the interoperability of the "image-rendering" property -- this property is explicitly a _hint_, to express author intent. Its description in the spec starts like this: # "The image-rendering property provides a hint # to the user-agent about what aspects of an # image are most important to preserve when the # image is scaled, to aid the user-agent in the # choice of an appropriate scaling algorithm. http://dev.w3.org/csswg/css-images-3/#propdef-image-rendering So, it's not required to behave exactly the same everywhere; it simply codifies an author's intent. (OK, I suppose it *is* required to behave exactly the same everywhere in the case of "pixelated" & upscaling, since that requires a particular algorithm, to achieve a particular effect. But other than that, it's purely a hint.) So, I don't think pixel-for-pixel-identical is a level of interoperability that's required or expected for this property, in general. Also, note that once followup-bug-1072703 is fixed, we'll be as interoperable with Chrome as our default downscaling behavior is with theirs. (which is probably pretty close, though I suspect not pixel-for-pixel identical.) ~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 2014-09-24, 9:12 PM, Daniel Holbert wrote: On 09/24/2014 09:32 AM, L. David Baron wrote: Or, alternatively, it seems like the use case here would be addressed by doing what the spec said before. Following up more on this: the CSSWG has now resolved to *allow* (but not require) the formerly-required-by-spec prettier downscaling behavior, per the first "RESOLVED" at the top of http://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html Hmm, doesn't that basically allow non-interoperable implementations? :( I think Jonas' idea on having separate properties for the upscale vs. downscale cases is much better. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1072703 to cover this. Given that the main use-cases for "image-rendering:pixelated" are for *upscaling*, I don't think the optional-better-downscaling-work should block us from shipping a straightforward (& spec-compliant) nearest-neighbor implementation for "pixelated". We can add better-downscaling logic separately, in the followup bug -- though it may even arrive in the same release where we ship "pixelated" (or if not that, soon after), since as noted in my other repsonse to dbaron, it's not *too* much work. So, what's Chrome's position with regards to this spec churn? Is what they're going to ship in Chrome 38 going to be interoperable with our implementation? ___ 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/24/2014 09:32 AM, L. David Baron wrote: > Or, alternatively, it seems like the use case here would be > addressed by doing what the spec said before. Following up more on this: the CSSWG has now resolved to *allow* (but not require) the formerly-required-by-spec prettier downscaling behavior, per the first "RESOLVED" at the top of http://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1072703 to cover this. Given that the main use-cases for "image-rendering:pixelated" are for *upscaling*, I don't think the optional-better-downscaling-work should block us from shipping a straightforward (& spec-compliant) nearest-neighbor implementation for "pixelated". We can add better-downscaling logic separately, in the followup bug -- though it may even arrive in the same release where we ship "pixelated" (or if not that, soon after), since as noted in my other repsonse to dbaron, it's not *too* much work. ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web APIs documentation meeting Friday at 10 AM Pacific time
The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend; if you're interested in ensuring that all Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-09-26. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you're unable to attend but have been working on documentation related to APIs, please add notes to the agenda about what you've been doing so we can share your progress. -- Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: @sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using protobuf in m-c
- Original Message - > Hey folks, > > We already have the protobuf library in the tree, and it seems to be > used for layer scope and webrtc. > > I'd like to use it for serializing heap snapshots in devtools code, but > I have a couple questions: > > * How do I integrate the compilation of the message description (.proto > file) into C source files with the build system? I'm not even sure if > layer scope and webrtc integrate this with the build system, or if the > just do it manually and check in the resulting files. I wasn't able to > determine by glancing over the moz.build files. You need to use the protocol compiler (protoc) which I did not import due to requests to keep the library small as possible. For an example please see http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/generate_csd.sh. > * Are there any other moz.build hoops I need to jump through to use > protobufs from within toolkit/devtools? I had to include DEFINES['GOOGLE_PROTOBUF_NO_RTTI'] = True in toolkit/components/downloads/moz.build. That was a long time ago so things may have changed. Thanks, Monica > > Thanks, > > Nick > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ 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 Wed, Sep 24, 2014 at 7:21 PM, Daniel Holbert wrote: > On 09/24/2014 07:38 AM, Ehsan Akhgari 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. > > > > So, what are we planning to do with -moz-crisp-edges? > > I'm not aware of any specific plans to change it at the moment. > > > I think keeping it in its current form may be pointless (unless if we > > know this is something that the Web depends on?) > > It's unclear to me whether the web depends on it. As a proxy, we use it > in 16 places within /browser. > > Moreover, note that this behavior is *only* available using per-browser > prefixed keywords; so I doubt authors have unprefixed fallback at this > point. So, unprefixing or removing "-moz-crisp-edges" would likely > break content at this point. (I'll bet authors will start including > unprefixed "pixelated" soon, though, because that'll be the only way to > get this behavior in Chrome, once it ships there.) > > > If I'm reading the > > spec correctly, we can actually unprefix it and make it equivalent to > > pixelated, but I'm not sure how valuable that is. > > We probably do want to eventually unprefix -moz-crisp-edges (and as you > say, we *could* do so now), but if we're planning to tweak which > algorithm we use (unclear), it might be wise to wait until we've done > that before unprefixing. > > > I think that this is > > allowed by the spec though, so perhaps it should be modified to say how > > crisp-edges must be different than pixelated. > > They don't have to be different. As Tab said on the Blink > intent-to-implement thread: > > Having "crisp-edges" act like "pixelated" is an > allowed implementation strategy. It's also allowed, > though, to be smarter when doing "crisp-edges", and > use an intelligent pixel-scaling algorithm, of > which there are many. > > "pixelated" was added by request of multiple users, who sometimes > literally want the "big pixel" look of plain nearest-neighbor > interpolation. > FWIW, NN interpolation is used by a lot of Flash content for the same reason, which is why implementing it was pretty high priority in Shumway. Given that, it's pretty likely that there's quite a bit of interest among web designers, too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Using protobuf in m-c
Hey folks, We already have the protobuf library in the tree, and it seems to be used for layer scope and webrtc. I'd like to use it for serializing heap snapshots in devtools code, but I have a couple questions: * How do I integrate the compilation of the message description (.proto file) into C source files with the build system? I'm not even sure if layer scope and webrtc integrate this with the build system, or if the just do it manually and check in the resulting files. I wasn't able to determine by glancing over the moz.build files. * Are there any other moz.build hoops I need to jump through to use protobufs from within toolkit/devtools? Thanks, Nick ___ 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/24/2014 07:38 AM, Ehsan Akhgari 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. > > So, what are we planning to do with -moz-crisp-edges? I'm not aware of any specific plans to change it at the moment. > I think keeping it in its current form may be pointless (unless if we > know this is something that the Web depends on?) It's unclear to me whether the web depends on it. As a proxy, we use it in 16 places within /browser. Moreover, note that this behavior is *only* available using per-browser prefixed keywords; so I doubt authors have unprefixed fallback at this point. So, unprefixing or removing "-moz-crisp-edges" would likely break content at this point. (I'll bet authors will start including unprefixed "pixelated" soon, though, because that'll be the only way to get this behavior in Chrome, once it ships there.) > If I'm reading the > spec correctly, we can actually unprefix it and make it equivalent to > pixelated, but I'm not sure how valuable that is. We probably do want to eventually unprefix -moz-crisp-edges (and as you say, we *could* do so now), but if we're planning to tweak which algorithm we use (unclear), it might be wise to wait until we've done that before unprefixing. > I think that this is > allowed by the spec though, so perhaps it should be modified to say how > crisp-edges must be different than pixelated. They don't have to be different. As Tab said on the Blink intent-to-implement thread: Having "crisp-edges" act like "pixelated" is an allowed implementation strategy. It's also allowed, though, to be smarter when doing "crisp-edges", and use an intelligent pixel-scaling algorithm, of which there are many. "pixelated" was added by request of multiple users, who sometimes literally want the "big pixel" look of plain nearest-neighbor interpolation. https://groups.google.com/a/chromium.org/d/msg/blink-dev/Q8N6FoeoPXI/hoECmv_OUkYJ ___ 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/24/2014 09:32 AM, L. David Baron wrote: > Or, alternatively, it seems like the use case here would be > addressed by doing what the spec said before. Is it really that > much harder to do? No, it's not much harder. > Is it just that we'd need to add another value to pass through > various layers of code, and then support that value? Correct -- we'd need to add a new enum value to GraphicsFilter, here... http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GraphicsFilter.h ...and then we'd need to adjust all the code that depends on GraphicsFilter enum-values to either have an "upscaling or downscaling?" check (or in some cases, if we can't tell about upscaling vs. downscaling at that point in the code, we'd need to ensure that all upstream or downstream code includes such a check). So: not particularly hard. Just some extra logic / complexity in a handful of places -- on the order of 10 places, perhaps, based on a MXR search for GraphicsFilter::FILTER_NEAREST. (That turns up 6 comparisons with "==" and 3 "case" statements, where we'd likely need to consider the new enum value as well, or convert out of it before we hit that code.) If "auto" downscaling actually makes a noticable difference for e.g. favicons, then I'm fine with adding back the distinction. (I'd be interested in seeing examples of its benefits, though; that would help make things more concrete.) > (Also, I think 'crisp-edges' in the spec is intended to be > algorithms better than nearest neighbor. I'm hesitant to unprefix > '-moz-crisp-edges' immediately, although we might consider just > removing it.) I agree that we shouldn't unprefix -moz-crisp-edges. I also don't think we should drop it quite yet, since it's the only way authors have had to request this behavior (and no browser release-version uses "pixelated" yet, so authors don't necessarily know to use that keyword yet either. Though I expect they soon will, given that this will be the only way to get NN-scaling in Chrome, once it's released there.) Maybe after we've shipped "pixelated" for a release, we can make the call to unprefix or drop/hide -moz-crisp-edges. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: BroadcastChannel API
Yes! Though as previously expressed, I don't think we should ship this until it supports sending Blobs. But we should definitely land preffed off as soon as patches are reviewed. / Jonas On Sep 24, 2014 3:45 AM, "Andrea Marchesini" wrote: > Summary: (from the spec) Pages on a single origin opened by the same user > in the same user agent but in different unrelated browsing contexts > sometimes need to send notifications to each other, for example "hey, the > user logged in over here, check your credentials again". > For elaborate cases, e.g. to manage locking of shared state, to manage > synchronisation of resources between a server and multiple local clients, > to share a WebSocket connection with a remote host, and so forth, shared > workers are the most appropriate solution. > For simple cases, though, where a shared worker would be an unreasonable > overhead, authors can use the simple channel-based broadcast mechanism > described in this section. > > Link to standard: > http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=966439 > > Platform coverage: All > > Preference behind which this will be implemented: > dom.broadcastchannel.enabled > > Note: Actually I've already implemented this API but I forgot to send this > intent to implement email months ago. It has received the first positive > review. I hope to land this API soon, if there are no objections. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ 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 Tuesday 2014-09-23 17:15 -0700, Justin Dolske wrote: > 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. Or, alternatively, it seems like the use case here would be addressed by doing what the spec said before. Is it really that much harder to do? Is it just that we'd need to add another value to pass through various layers of code, and then support that value? Or is supporting that value actually hard? (Also, I think 'crisp-edges' in the spec is intended to be algorithms better than nearest neighbor. I'm hesitant to unprefix '-moz-crisp-edges' immediately, although we might consider just removing it.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: resource timing
On 24/09/14 14:27, Valentin Gosu wrote: > On 24 September 2014 12:08, James Graham wrote: > >> On 24/09/14 02:11, Valentin Gosu wrote: >> >>> == 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 >> >> If this test is buggy, have we submitted patches? >> > > I have filed 3 bugs for the test: > https://bugzilla.mozilla.org/show_bug.cgi?id=1002855#c18 > I intend to submit pull requests for this as soon as possible. Great! Let me know if you need any help. ___ 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, 7:07 PM, Daniel Holbert 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. Great! 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. So, what are we planning to do with -moz-crisp-edges? I think keeping it in its current form may be pointless (unless if we know this is something that the Web depends on?). If I'm reading the spec correctly, we can actually unprefix it and make it equivalent to pixelated, but I'm not sure how valuable that is. I think that this is allowed by the spec though, so perhaps it should be modified to say how crisp-edges must be different than pixelated. (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.) But there is nothing in the current spec text requiring the two to be different, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: resource timing
On 24 September 2014 12:08, James Graham wrote: > On 24/09/14 02:11, Valentin Gosu wrote: > > > == 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 > > If this test is buggy, have we submitted patches? > I have filed 3 bugs for the test: https://bugzilla.mozilla.org/show_bug.cgi?id=1002855#c18 I intend to submit pull requests for this as soon as possible. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: BroadcastChannel API
Summary: (from the spec) Pages on a single origin opened by the same user in the same user agent but in different unrelated browsing contexts sometimes need to send notifications to each other, for example "hey, the user logged in over here, check your credentials again". For elaborate cases, e.g. to manage locking of shared state, to manage synchronisation of resources between a server and multiple local clients, to share a WebSocket connection with a remote host, and so forth, shared workers are the most appropriate solution. For simple cases, though, where a shared worker would be an unreasonable overhead, authors can use the simple channel-based broadcast mechanism described in this section. Link to standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=966439 Platform coverage: All Preference behind which this will be implemented: dom.broadcastchannel.enabled Note: Actually I've already implemented this API but I forgot to send this intent to implement email months ago. It has received the first positive review. I hope to land this API soon, if there are no objections. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: BroadcastChannel API
Summary: (from the spec) Pages on a single origin opened by the same user in the same user agent but in different unrelated browsing contexts sometimes need to send notifications to each other, for example "hey, the user logged in over here, check your credentials again". For elaborate cases, e.g. to manage locking of shared state, to manage synchronisation of resources between a server and multiple local clients, to share a WebSocket connection with a remote host, and so forth, shared workers are the most appropriate solution. For simple cases, though, where a shared worker would be an unreasonable overhead, authors can use the simple channel-based broadcast mechanism described in this section. Link to standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=966439 Platform coverage: All Preference behind which this will be implemented: dom.broadcastchannel.enabled Note: Actually I've already implemented this API but I forgot to send this intent to implement email months ago. It has received the first positive review. I hope to land this API soon, if there are no objections. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: resource timing
On 24/09/14 02:11, Valentin Gosu wrote: > == 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 If this test is buggy, have we submitted patches? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
