Re: Retina display support
Hi Markus, We already have this setting in Info.plist of app. I have tried both values NSApplication and GeckoNSApplication but no effect . Is there anything else that needs to be done. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 30/05/14 18:53, Joshua Cranmer wrote: Forgive me, but that sounds like I'm going to propose a solution with one glaring flaw that has always sunk it in the past, and then gloss over that flaw by saying 'I don't have the security experience - someone else fix it'. Actually, that is essentially what I'm saying. I know other people at Mozilla have good security backgrounds and can discuss the issue, and I was hoping that they could weigh in with suggestions on this thread. I acknowledge that the re-keying is a difficult issue, but I also don't have the time to do the research myself on this topic, since I'm way backed up on a myriad of other obligations. https://www.youtube.com/watch?v=BKorP55Aqvgfeature=youtu.be :-) The EFF does things that aren't public?! :) It would appear so. There are many reasons why this might be - privacy, lack of time to publish, etc. I haven't asked them. More seriously, are they actively attempting to detect potential MITMs, and would they announce if they did detect one? I don't know, and presumably yes :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
On 30/05/2014 16:16, andreas@gmail.com wrote: Please read my email again. This kind of animation cannot be rendered with high FPS by any engine. This doesn't make sense. Avih posted numbers sans-OMTC, and the same machine he used that doesn't manage to get 60fps with OMTC gets almost 200fps without it. IOW, we have real data that disproves your claim that this is not possible. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on sheriff-assisted checkin-needed bugs
Playing devil's advocate for a bit - are there more non-checkin-needed backouts? That is, people who, err, feel it is unnecessary to push to try to land something with checkin-needed, and therefore then land it themselves and burn the tree? :-) And also: has the throughput in checkin-needed landings gone down, ie are we trading this off against making it a teeny bit harder for people to contribute? (not intending a value judgment there - it is likely still the right thing to do, but it would be good to know) ~ Gijs On 30/05/2014 16:17, Ryan VanderMeulen wrote: Just as a quick follow-up to this - we're already seeing much lower checkin-needed backout rates since this change went into affect, so thank you all for your help! -Ryan - Original Message - From: Ryan VanderMeulen rvandermeu...@mozilla.com To: dev-b2g dev-...@lists.mozilla.org, dev.platform dev-platform@lists.mozilla.org, dev-g...@lists.mozilla.org Cc: Sheriffs sheri...@mozilla.com Sent: Friday, May 16, 2014 4:54:29 PM Subject: Update on sheriff-assisted checkin-needed bugs As many of you are aware, the sheriff team has been assisting with landing checkin-needed bugs for some time now. However, we've also had to deal with the fallout of a higher than average bustage frequency from them. As much as we enjoy shooting ourselves in the foot, our team has decided that we needed to tweak our process a bit to avoid tree closures and wasted time and energy. Therefore, our team has decided that we will now require that a link to a recent Try run be provided when requesting checkin before we will land the patch. To be clear, this *ONLY* affects checkin-needed bugs where we're assisting with the landing. We have no desire to police what other developers do before pushing. As has always been the case, developers are expected to ensure that their patches have received adequate testing prior to pushing whether they are receiving our assistance or not. Our team is also not going to dictate which specific builds/tests are required. We're not experts in your code and we'll defer to your judgment as to what counts as sufficient testing. As mentioned earlier today in another post, if in doubt, we do have a set of general best practices for Try that can be used as a guide [1]. We just want to ensure that patches have at least received some baseline level of testing before being pushed to production. We've been testing the water with this policy for the past couple weeks and have already seen a reduction in the number of backouts needed. For those of you mentoring bugs for new contributors, please also keep this in mind in order to keep patches from being held up in landing. And consider vouching for Level 1 commit access to further empower those contributors! Thanks! -Ryan [1] https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Standardized assertion methods
Dear unit test writers, As a happy few of you might already know, we introduced a standalone, versatile class of assertion methods with Assert.jsm[1], which implements the CommonJS Unit Testing specification version 1.1[2]. These methods were already available to you in the global `Assert` namespace in XPCShell-test, Mochitest-browser and Mochitest-chrome tests. Since last Friday[3], each assertion method in Assert.jsm is available in the global scope of a unit test as well. Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated in favour of the Assert.jsm ones. Here’s a short table of what this means in practice: * do_check_eq(a, b) — equal(a, b) * do_check_neq(a, b) — notEqual(a, b) * do_check_true(expr) — ok(expr) * do_check_false(expr) — ok(!expr) * do_check_null(expr) — equal(expr, null) * do_check_matches(a, b) — deepEqual(a, b) (undocumented XPCShell-test feature) Please note that we did NOT replace all occurrences with the Assert.jsm equivalents, we merely marked them as ‘deprecated’ in the docs[4]. We’re planning to do the same for Mochitest-browser tests in bug 1018226. Now, dear writer and reviewer of unit tests, I’d like to ask if you could take note of this change and apply it to new tests that’ll land in the tree. Finally, I’d like to thank Gregory Szorc, Ted Mielczarek, Blair McBride and many others who helped getting this change worked out, integrated and so on. But we’re not done yet! There are more things we can do to make reading, writing and tracing tests easier and more fun! Have fun, Mike. [1] https://developer.mozilla.org/en/docs/Mozilla/JavaScript_code_modules/Assert.jsm [2] http://wiki.commonjs.org/wiki/Unit_Testing/1.1 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1014482 [4] https://developer.mozilla.org/en-US/docs/Mozilla/QA/Writing_xpcshell-based_unit_tests [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1018226 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
Should we adopt these for SpiderMonkey's test suites, too? Porting tests between suites isn't something that's done frequently, but there are people writing tests for more than one suite, and being able to use the same assertion methods everywhere would be helpful for that. On Mon, Jun 2, 2014 at 12:37 PM, Mike de Boer mdeb...@mozilla.com wrote: Dear unit test writers, As a happy few of you might already know, we introduced a standalone, versatile class of assertion methods with Assert.jsm[1], which implements the CommonJS Unit Testing specification version 1.1[2]. These methods were already available to you in the global `Assert` namespace in XPCShell-test, Mochitest-browser and Mochitest-chrome tests. Since last Friday[3], each assertion method in Assert.jsm is available in the global scope of a unit test as well. Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated in favour of the Assert.jsm ones. Here’s a short table of what this means in practice: * do_check_eq(a, b) — equal(a, b) * do_check_neq(a, b) — notEqual(a, b) * do_check_true(expr) — ok(expr) * do_check_false(expr) — ok(!expr) * do_check_null(expr) — equal(expr, null) * do_check_matches(a, b) — deepEqual(a, b) (undocumented XPCShell-test feature) Please note that we did NOT replace all occurrences with the Assert.jsm equivalents, we merely marked them as ‘deprecated’ in the docs[4]. We’re planning to do the same for Mochitest-browser tests in bug 1018226. Now, dear writer and reviewer of unit tests, I’d like to ask if you could take note of this change and apply it to new tests that’ll land in the tree. Finally, I’d like to thank Gregory Szorc, Ted Mielczarek, Blair McBride and many others who helped getting this change worked out, integrated and so on. But we’re not done yet! There are more things we can do to make reading, writing and tracing tests easier and more fun! Have fun, Mike. [1] https://developer.mozilla.org/en/docs/Mozilla/JavaScript_code_modules/Assert.jsm [2] http://wiki.commonjs.org/wiki/Unit_Testing/1.1 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1014482 [4] https://developer.mozilla.org/en-US/docs/Mozilla/QA/Writing_xpcshell-based_unit_tests [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1018226 ___ 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: Standardized assertion methods
Mike de Boer wrote: * do_check_eq(a, b) — equal(a, b) There's also strictEqual(a, b) for those like me who were wondering. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
Yes, that’d be very nice to have! In a perfect world, all the test suites/ runners we have end up using the same assertion methods. This would indeed greatly improve the portability of individual tests. Thanks for suggesting this, Till! On 02 Jun 2014, at 12:56, Till Schneidereit t...@tillschneidereit.net wrote: Should we adopt these for SpiderMonkey's test suites, too? Porting tests between suites isn't something that's done frequently, but there are people writing tests for more than one suite, and being able to use the same assertion methods everywhere would be helpful for that. On Mon, Jun 2, 2014 at 12:37 PM, Mike de Boer mdeb...@mozilla.com wrote: Dear unit test writers, As a happy few of you might already know, we introduced a standalone, versatile class of assertion methods with Assert.jsm[1], which implements the CommonJS Unit Testing specification version 1.1[2]. These methods were already available to you in the global `Assert` namespace in XPCShell-test, Mochitest-browser and Mochitest-chrome tests. Since last Friday[3], each assertion method in Assert.jsm is available in the global scope of a unit test as well. Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated in favour of the Assert.jsm ones. Here’s a short table of what this means in practice: * do_check_eq(a, b) — equal(a, b) * do_check_neq(a, b) — notEqual(a, b) * do_check_true(expr) — ok(expr) * do_check_false(expr) — ok(!expr) * do_check_null(expr) — equal(expr, null) * do_check_matches(a, b) — deepEqual(a, b) (undocumented XPCShell-test feature) Please note that we did NOT replace all occurrences with the Assert.jsm equivalents, we merely marked them as ‘deprecated’ in the docs[4]. We’re planning to do the same for Mochitest-browser tests in bug 1018226. Now, dear writer and reviewer of unit tests, I’d like to ask if you could take note of this change and apply it to new tests that’ll land in the tree. Finally, I’d like to thank Gregory Szorc, Ted Mielczarek, Blair McBride and many others who helped getting this change worked out, integrated and so on. But we’re not done yet! There are more things we can do to make reading, writing and tracing tests easier and more fun! Have fun, Mike. [1] https://developer.mozilla.org/en/docs/Mozilla/JavaScript_code_modules/Assert.jsm [2] http://wiki.commonjs.org/wiki/Unit_Testing/1.1 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1014482 [4] https://developer.mozilla.org/en-US/docs/Mozilla/QA/Writing_xpcshell-based_unit_tests [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1018226 ___ 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: DOMMatrix
2014-06-01 23:19 GMT-04:00 Rik Cabanier caban...@gmail.com: On Sun, Jun 1, 2014 at 3:11 PM, Benoit Jacob jacob.benoi...@gmail.com wrote: 2014-05-31 0:40 GMT-04:00 Rik Cabanier caban...@gmail.com: Objection #3: I dislike the way that this API exposes multiplication order. It's not obvious enough which of A.multiply(B) and A.multiplyBy(B) is doing A=A*B and which is doing A=B*A. The by methods do the transformation in-place. In this case, both are A = A * B Maybe you're thinking of preMultiply? Ah, I was totally confused by the method names. Multiply is already a verb, and the method name multiply already implicitly means multiply *by*. So it's very confusing that there is another method named multiplyBy. Yeah, we had discussion on that. 'by' is not ideal, but it is much shorter than 'InPlace'. Do you have a suggestion to improve the name? My suggestion was the one below that part (multiply-product, multiplyBy-multiply) but it seems that that's moot because: Methods on DOMMatrixReadOnly are inconsistently named: some, like multiply, are named after the /verb/ describing what they /do/, while others, like inverse, are named after the /noun/ describing what they /return/. Choose one and stick to it; my preference goes to the latter, i.e. rename multiply to product in line with the existing inverse and then the DOMMatrix.multiplyBy method can drop the By and become multiply. If you do rename multiply to product that leads to the question of what preMultiply should become. In an ideal world (not commenting on whether that's a thing we can get on the Web), product would be a global function, not a class method, so you could let people write product(X, Y) or product(Y, X) and not have to worry about naming differently the two product orders. Unfortunately, we're stuck with the API names that SVG gave to its matrix. The only way to fix this is to duplicate the API and support both old and new names which is very confusing, Sounds like the naming is not even up for discussion, then? In that case, what is up for discussion? That's basically the core disagreement here: I'm not convinced that just because something is in SVG implies that it should be propagated as a blessed abstraction for the rest of the Web. Naming and branding matter: something named SVGMatrix clearly suggests should be used for dealing with SVG while something named DOMMatrix sounds like it's recommended for use everywhere on the Web. I would rather have SVG keep its own matrix class while the rest of the Web gets something nicer. Objection #4: By exposing a inverse() method but no solve() method, this API will encourage people who have to solve linear systems to do so by doing matrix.inverse().transformPoint(...), which is inefficient and can be numerically unstable. But then of course once we open the pandora box of exposing solvers, the API grows a lot more. My point is not to suggest to grow the API more. My point is to discourage you and the W3C from getting into the matrix API design business. Matrix APIs are bound to either grow big or be useless. I believe that the only appropriate Matrix interface at the Web API level is a plain storage class, with minimal getters (basically a thin wrapper around a typed array without any nontrivial arithmetic built in). We already went over this at length about a year ago. Dirk's been asking for feedback on this interface on www-style and public-fx so can you raise your concerns there? Just keep in mind that we have to support the SVGMatrix and CSSMatrix interfaces. My ROI for arguing on standards mailing on matrix math topics lists has been very low, presumably because these are specialist topics outside of the area of expertise of these groups. It is a constant struggle. We need to strike a balance between mathematicians and average authors. Stay with it and prepare to repeat yourself; it's frustrating for everyone involved. If you really don't want to participate anymore, we can get to an agreement here and I can try to convince the others. I'm happy to continue to provide input on matrix API design or other math topics. I can't go spontaneously participate in conversations on all the mailing lists though; dev-platform is the only one that I monitor closely, and where I'm very motivated to get involved, because what really makes my life harder is if the wrong API gets implemented in Gecko. Here are a couple more objections by the way: Objection #5: The isIdentity() method has the same issue as was described about is2D() above: as matrices get computed, they are going to jump unpredicably between being exactly identity and not. People using isIdentity() to jump between code paths are going to get unexpected jumps between code paths i.e. typically performance cliffs, or worse if they start asserting that a matrix should or should not be exactly identity. For that reason, I would remove
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 06/02/2014 01:49 PM, Mike de Boer wrote: Yes, that’d be very nice to have! In a perfect world, all the test suites/ runners we have end up using the same assertion methods. This would indeed greatly improve the portability of individual tests. As I said before (but was ignored), the more sensible approach to achieve that goal would be to adopt the testharness.js methods, which are also more consistently named, have better behaviour for the shorter-name methods, and are documented more clearly. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMiNatrix
On 02/06/2014 05:05, Bob wrote: In a play on words, is this some kind of SM (not SeaMonkey) feature? No it isn't. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On 2014-05-30, at 21:00, Benoit Jacob jacob.benoi...@gmail.com wrote: 2x3 matrices representing affine 2D transformations; this mode switch corresponds to the is2D() getter Am I the only one that finds this method entirely unintuitive? After looking at only the IDL, admittedly, is2D() === true. Is the name intended to convey the fact that this is a highly specialised matrix, because it doesn’t really do that for me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reminder: Rendering meeting today, 2:30pm PDT
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, at 2:30pm PDT. The next meeting will take place today, Monday, June 2nd at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-06-02#Agenda San Francisco - Monday, 2:30pm Winnipeg - Monday, 4:30pm Toronto - Monday, 5:30pm GMT/UTC - Monday, 22:30 Paris - Monday, 11:30pm Taipei - Tuesday, 6:30am Brisbane - Tuesday, 8:30am Auckland - Tuesday, 11:30am http://arewemeetingyet.com/Toronto/2014-06-02/17:30/Rendering%20Meeting Video conferencing: Vidyo room Graphics (9366) https://v.mozilla.com/flex.html?roomdirect.htmlkey=FILzKzPcA6W2 Phone conferencing: +1 650 903 0800 x92 Conf# 99366 +1 416 848 3114 x92 Conf# 99366 +1 800 707 2533 (pin 369) Conf# 99366 -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/2014 11:37 AM, Mike de Boer wrote: Since last Friday[3], each assertion method in Assert.jsm is available in the global scope of a unit test as well. Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated in favour of the Assert.jsm ones. I think it's a very good thing that finally someone is doing the work of moving various different test suites towards unified assertion methods (regardless of the actual choice of which methods they are)! Here’s a short table of what this means in practice: * do_check_eq(a, b) — equal(a, b) * do_check_neq(a, b) — notEqual(a, b) * do_check_true(expr) — ok(expr) * do_check_false(expr) — ok(!expr) * do_check_null(expr) — equal(expr, null) * do_check_matches(a, b) — deepEqual(a, b) (undocumented XPCShell-test feature) Have you considered requiring test cases to use the the Assert. namespace explicitly? I would find that style more readable, and also assertions easier to find when scanning the code. And they're still shorter than current assertion functions in xpcshell tests. Especially the less-known Assert.throws(function, exception) seems to read better than just throws(function, exception). For example compare this snippet from the referenced bug... + equal(aPacket.type, paused); + let env = aPacket.frame.environment; + equal(env.type, function); + equal(env.function.name, banana3); + let parent = env.parent; + equal(parent.type, block); + ok(banana3 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, function); + equal(parent.function.name, banana2); + parent = parent.parent; + equal(parent.type, block); + ok(banana2 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, block); + ok(banana2 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, function); + equal(parent.function.name, banana); ...with this modified one: + Assert.equal(aPacket.type, paused); + let env = aPacket.frame.environment; + Assert.equal(env.type, function); + Assert.equal(env.function.name, banana3); + let parent = env.parent; + Assert.equal(parent.type, block); + Assert.ok(banana3 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, function); + Assert.equal(parent.function.name, banana2); + parent = parent.parent; + Assert.equal(parent.type, block); + Assert.ok(banana2 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, block); + Assert.ok(banana2 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, function); + Assert.equal(parent.function.name, banana); Much easier to visually separate what the test is doing from the intermixed calls that check the intermediate results. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 8:04 AM, Martin Thomson m...@mozilla.com wrote: On 2014-05-30, at 21:00, Benoit Jacob jacob.benoi...@gmail.com wrote: 2x3 matrices representing affine 2D transformations; this mode switch corresponds to the is2D() getter Am I the only one that finds this method entirely unintuitive? After looking at only the IDL, admittedly, is2D() === true. Is the name intended to convey the fact that this is a highly specialised matrix, because it doesn’t really do that for me. it conveys that this is a 2d matrix and that you can ignore the 3d components. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
Warning: pet peeve coming up. I agree we should separate these things more clearly. I don't think making people type the same 7 characters repeatedly is a good way to do that. I think we should be more liberal with using blank lines instead. It's too often I see 30-line blocks of code with not a single line of whitespace separating logical blocks, leaving the (vegetarian or beef-greedy) reader the tedious tasks of separating out the meatballs from the metaphorical spaghetti code. Concretely, IMO in the code you cite there should be a blank line before each of the 'parent' reassignments. ~ Gijs On 02/06/2014 16:39, Paolo Amadini wrote: On 6/2/2014 11:37 AM, Mike de Boer wrote: Since last Friday[3], each assertion method in Assert.jsm is available in the global scope of a unit test as well. Now we can say that the ‘old’ XPCShell-test assertion methods are deprecated in favour of the Assert.jsm ones. I think it's a very good thing that finally someone is doing the work of moving various different test suites towards unified assertion methods (regardless of the actual choice of which methods they are)! Here’s a short table of what this means in practice: * do_check_eq(a, b) — equal(a, b) * do_check_neq(a, b) — notEqual(a, b) * do_check_true(expr) — ok(expr) * do_check_false(expr) — ok(!expr) * do_check_null(expr) — equal(expr, null) * do_check_matches(a, b) — deepEqual(a, b) (undocumented XPCShell-test feature) Have you considered requiring test cases to use the the Assert. namespace explicitly? I would find that style more readable, and also assertions easier to find when scanning the code. And they're still shorter than current assertion functions in xpcshell tests. Especially the less-known Assert.throws(function, exception) seems to read better than just throws(function, exception). For example compare this snippet from the referenced bug... + equal(aPacket.type, paused); + let env = aPacket.frame.environment; + equal(env.type, function); + equal(env.function.name, banana3); + let parent = env.parent; + equal(parent.type, block); + ok(banana3 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, function); + equal(parent.function.name, banana2); + parent = parent.parent; + equal(parent.type, block); + ok(banana2 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, block); + ok(banana2 in parent.bindings.variables); + parent = parent.parent; + equal(parent.type, function); + equal(parent.function.name, banana); with this modified one: + Assert.equal(aPacket.type, paused); + let env = aPacket.frame.environment; + Assert.equal(env.type, function); + Assert.equal(env.function.name, banana3); + let parent = env.parent; + Assert.equal(parent.type, block); + Assert.ok(banana3 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, function); + Assert.equal(parent.function.name, banana2); + parent = parent.parent; + Assert.equal(parent.type, block); + Assert.ok(banana2 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, block); + Assert.ok(banana2 in parent.bindings.variables); + parent = parent.parent; + Assert.equal(parent.type, function); + Assert.equal(parent.function.name, banana); Much easier to visually separate what the test is doing from the intermixed calls that check the intermediate results. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 02 Jun 2014, at 17:39, Paolo Amadini paolo.02@amadzone.org wrote: Have you considered requiring test cases to use the the Assert. namespace explicitly? I would find that style more readable, and also assertions easier to find when scanning the code. And they're still shorter than current assertion functions in xpcshell tests. I agree with you on that point, it makes the assertions easier to notice, so that’s why we’ve kept the `Assert.` namespace alive. In fact, I ‘forgot’ to remove the namespaced versions from https://developer.mozilla.org/en-US/docs/Mozilla/QA/Writing_xpcshell-based_unit_tests! It’s up to a matter of taste, I guess… Both are possible at the moment. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On 2014-06-02, at 08:53, Rik Cabanier caban...@gmail.com wrote: it conveys that this is a 2d matrix and that you can ignore the 3d components. Maybe you misunderstood what I was implying. You are describing an intended application of the matrix to 2d or 3d graphics. The problem is that the is2D() method is applicable to what appears to be a generic object. That object has a name “DOMMatrix” which implies a general capability that isn’t present. However, when someone says matrix [1], I think matrix. My understanding of matrices extends beyond 4x4 and 2x3. It’s understandable perhaps that the matrix object is 2-dimensional only, because that is highly useful for the application you have in mind, and a lot more besides. I think that a lot of this sort of confusion would be remedied by having a different name, in both cases. CSSMatrix is heaps better (but there I might be demonstrating ignorance of “CSS”), and is2x3() would also help. —Martin [1] ...here a DOM prefix has been rendered effectively meaningless through overuse. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/2014 4:59 PM, Ehsan Akhgari wrote: I'm _pretty_ sure that the answer is no for mochitest-chrome at least. Are we running these tests out-of-tree in other environments? Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/2014 4:51 PM, Gijs Kruitbosch wrote: Concretely, IMO in the code you cite there should be a blank line before each of the 'parent' reassignments. I definitely agree, and I would also use the Assert. prefix to make the separation between action and check clearer (while if I understand correctly you'd prefer the shorter option). Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 10:56 AM, Nick Alexander nalexan...@mozilla.com wrote: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? It looks like an oversight. I'll ask Dirk to update it. But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On Mon, Jun 2, 2014 at 12:27 PM, Paolo Amadini paolo.02@amadzone.org wrote: On 6/2/2014 4:59 PM, Ehsan Akhgari wrote: I'm _pretty_ sure that the answer is no for mochitest-chrome at least. Are we running these tests out-of-tree in other environments? Do you mean by just opening the page in the browser? I don't think that's a common use case. But why do you ask? -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
2014-06-02 14:06 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com: 2014-06-02 13:56 GMT-04:00 Nick Alexander nalexan...@mozilla.com: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. The way that propagating an is identity flag is better than determining that from the matrix coefficients, is that it's predictable. People are going to have matrices that are the result of various arithmetic operations, that are close to identity but most of the time not exactly identity. On these matrices, I would like isIdentity() to consistently return false, instead of returning false 99.99% of the time and then suddenly accidentally returning true when a little miracle happens and a matrix happens to be exactly identity. ...but, to not lose sight of what I really want: I am still not convinced that we should have a isIdentity() method at all, and by default I would prefer no such method to exist. I was only saying the above _if_ we must have a isIdentity method. Benoit Benoit 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: DOMMatrix
2014-06-02 13:56 GMT-04:00 Nick Alexander nalexan...@mozilla.com: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. The way that propagating an is identity flag is better than determining that from the matrix coefficients, is that it's predictable. People are going to have matrices that are the result of various arithmetic operations, that are close to identity but most of the time not exactly identity. On these matrices, I would like isIdentity() to consistently return false, instead of returning false 99.99% of the time and then suddenly accidentally returning true when a little miracle happens and a matrix happens to be exactly identity. Benoit 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
xpcom supported
developing .so / dylib / .dll using xulrunner sdk and then calling it in extension in javascript is that still supported. i see very poor documentation on the web on it. and no good working example. can someone confirm latest xulrunner sdk supports and an extension can be developed using c++ xpcom. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: xpcom supported
On 6/2/14, 2:38 PM, savani1ama...@gmail.com wrote: developing .so / dylib / .dll using xulrunner sdk and then calling it in extension in javascript is that still supported. i see very poor documentation on the web on it. and no good working example. Savani, you have posted variants of this same question to three different lists within the past hour. Please be patient when you ask questions and try to avoid list-hopping. Please direct followup replied to mozilla.dev.extensions. i am developing a c++ component using xpcom. i could develop an .so file using xulrunner-sdk. however xpcom viewer doesnt recognize my component. so basically something wrong in manifest file or rdf.. how to debug this? .so file seems to be in correct format .. i mean i started using it in c program and it asks for nsisupport. so i am assuming .so file is not corrupted or anything.( just thought i should check that out first) The best tool for this is the browser console. 1) Check and see whether there are any messages related to component registration. I've tried to add comprehensive error reporting to the registration code. 2) Check for the presence of your contract: Components.classes[@whatever/my-component;1] 3) Try to create the component: Components.classes[@whatever/my-component;1].createInstance(); 4) If you added a new interface, test for it: Components.interfaces.nsIMyInterface; 4) Try to create the component using your new interface: Components.classes[@whatever/my-component;1].createInstance(Components.interfaces.nsIMyInterface); can someone confirm latest xulrunner sdk supports and an extension can be developed using c++ xpcom. Compiled components are supposed to work, yes. Several addon authors are still using them. However, they are strongly discouraged and we may decide to remove support for them in a future version of Firefox. You're encouraged to write your addon entirely in JavaScript if possible; if you must interface with external binary code, please consider loading a binary shim using JS-ctypes. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Retina display support
On 02.06.14 08:42, bhargava.animes...@gmail.com wrote: Hi Markus, We already have this setting in Info.plist of app. I have tried both values NSApplication and GeckoNSApplication but no effect . Is there anything else that needs to be done. Is gfx.hidpi.enabled set to 2? Other than that I don't have any ideas. -Markus ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/14, 3:34 PM, Paolo Amadini wrote: It seems to me that if we don't have external compatibility needs, we might as well move mochitests to use a set of assertion methods that is the same as xpcshell and maybe other test suites. Yes, but imho we should be moving xpcshell in the direction of the ok/is bits that mochitests use instead of moving mochitests in the direction of longer function names. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Retina display support
Am 30.05.2014 08:38, bhargava.animes...@gmail.com wrote: Hi, I have two different applications , both of them use gecko SDK version 2.0 for embedded browser. That's Firefox 4, isn't it? Are you sure that retina support is already available in this version? Google says it was added in Firefox 18, i.e. Gecko 18. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Tree Closure Stats - May 2014
Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions. _Mozilla Inbound _Closures due to test failures on Inbound are slightly higher than normal. 2014-05 checkin-compilation: 23:53:02 checkin-test: 3 days, 0:45:33 infra: 11:52:28 planned: 2:34:02 total: 4 days, 15:05:05_ Mozilla Central _ 2014-05 checkin-compilation: 0:02:34 checkin-test: 12:57:52 infra: 12:58:48 total: 1 day, 1:59:14 _ Fx-Team _ 2014-05 checkin-compilation: 0:08:23 checkin-test: 20:24:28 infra: 13:42:36 no reason: 0:00:03 total: 1 day, 10:15:30_ B2G Inbound_ The higher than normal infra closure was down to a 3rd party repository having their master branch tracked which was unfortunately broken. 2014-05 backlog: 6:08:36 checkin-compilation: 1 day, 14:58:51 checkin-test: 15:15:13 infra: 2 days, 1:17:26 total: 4 days, 13:40:06 If you would like to see how this compares to previous months please see http://futurama.theautomatedtester.co.uk/ David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On Mon, Jun 2, 2014 at 4:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/2/14, 3:34 PM, Paolo Amadini wrote: It seems to me that if we don't have external compatibility needs, we might as well move mochitests to use a set of assertion methods that is the same as xpcshell and maybe other test suites. Yes, but imho we should be moving xpcshell in the direction of the ok/is bits that mochitests use instead of moving mochitests in the direction of longer function names. Yes, this was precisely my point. -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Retina display support
On 02.06.14 22:10, Philipp Wagner wrote: Am 30.05.2014 08:38, bhargava.animes...@gmail.com wrote: Hi, I have two different applications , both of them use gecko SDK version 2.0 for embedded browser. That's Firefox 4, isn't it? Are you sure that retina support is already available in this version? Google says it was added in Firefox 18, i.e. Gecko 18. I missed this bit. You're right! With Gecko 2.0 it won't work. -Markus ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 11:08 AM, Benoit Jacob jacob.benoi...@gmail.com wrote: 2014-06-02 14:06 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com: 2014-06-02 13:56 GMT-04:00 Nick Alexander nalexan...@mozilla.com: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. The way that propagating an is identity flag is better than determining that from the matrix coefficients, is that it's predictable. People are going to have matrices that are the result of various arithmetic operations, that are close to identity but most of the time not exactly identity. On these matrices, I would like isIdentity() to consistently return false, instead of returning false 99.99% of the time and then suddenly accidentally returning true when a little miracle happens and a matrix happens to be exactly identity. ...but, to not lose sight of what I really want: I am still not convinced that we should have a isIdentity() method at all, and by default I would prefer no such method to exist. I was only saying the above _if_ we must have a isIdentity method. Scanning through the mozilla codebase, IsIdentity is used to make decisions if objects were transformed. This seems to match how we use Identity() internally. Since this seems useful for native applications, there's no reason why this wouldn't be the case for the web platform (aka blink's rational web platform principle). If for some reason the author *really* wants to know if the matrix is identity, he can calculate it manually. I would be fine with keeping this as an internal flag and defining this behavior normative. ___ dev-platform mailing list dev-platform@lists.mozilla.org
Re: Standardized assertion methods
Do either of you have reasoning for that other than it looks better to me? I personally think consistency trumps any personal preferences based on length/concision, as long as what we end up with isn't unreasonably long/verbose. Gavin On Mon, Jun 2, 2014 at 4:47 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On Mon, Jun 2, 2014 at 4:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/2/14, 3:34 PM, Paolo Amadini wrote: It seems to me that if we don't have external compatibility needs, we might as well move mochitests to use a set of assertion methods that is the same as xpcshell and maybe other test suites. Yes, but imho we should be moving xpcshell in the direction of the ok/is bits that mochitests use instead of moving mochitests in the direction of longer function names. Yes, this was precisely my point. -- Ehsan http://ehsanakhgari.org/ ___ 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: DOMMatrix
On Tue, Jun 3, 2014 at 4:24 AM, Martin Thomson m...@mozilla.com wrote: it conveys that this is a 2d matrix and that you can ignore the 3d components. Maybe you misunderstood what I was implying. You are describing an intended application of the matrix to 2d or 3d graphics. The problem is that the is2D() method is applicable to what appears to be a generic object. That object has a name “DOMMatrix” which implies a general capability that isn’t present. However, when someone says matrix [1], I think matrix. My understanding of matrices extends beyond 4x4 and 2x3. It’s understandable perhaps that the matrix object is 2-dimensional only, because that is highly useful for the application you have in mind, and a lot more besides. The DOM prefix is present because we don't want to squat on Matrix and various different DOM APIs need this object. The most general thing those APIs need is a matrix representation of 3D projective transforms, so that's what DOMMatrix currently provides. I find it hard to imagine needing to go beyond that; I cannot forsee Web APIs needing to interface with a general linear algebra package. If they do, extending DOMMatrix and creating an entirely new type (GeneralMatrix?) are both viable options. And keep in mind that in Web development the name of an interface type rarely shows up in application code (generally just constructors and instanceof). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
2014-06-02 17:13 GMT-04:00 Rik Cabanier caban...@gmail.com: On Mon, Jun 2, 2014 at 11:08 AM, Benoit Jacob jacob.benoi...@gmail.com wrote: 2014-06-02 14:06 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com: 2014-06-02 13:56 GMT-04:00 Nick Alexander nalexan...@mozilla.com: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. The way that propagating an is identity flag is better than determining that from the matrix coefficients, is that it's predictable. People are going to have matrices that are the result of various arithmetic operations, that are close to identity but most of the time not exactly identity. On these matrices, I would like isIdentity() to consistently return false, instead of returning false 99.99% of the time and then suddenly accidentally returning true when a little miracle happens and a matrix happens to be exactly identity. ...but, to not lose sight of what I really want: I am still not convinced that we should have a isIdentity() method at all, and by default I would prefer no such method to exist. I was only saying the above _if_ we must have a isIdentity method. Scanning through the mozilla codebase, IsIdentity is used to make decisions if objects were transformed. This seems to match how we use Identity() internally. Since this seems useful for native applications, there's no reason why this wouldn't be the case for the web platform (aka blink's rational web platform principle). If for some reason the author *really* wants to know if the matrix is identity, he can calculate it manually. I would be fine with keeping this as an internal flag and defining this behavior normative. Gecko's existing code really isn't authoritative on matrix
Re: Can we remove NS_HIDDEN, NS_HIDDEN_(...)?
On Wed, May 21, 2014 at 9:53 PM, Robert O'Callahan rob...@ocallahan.org wrote: Android and B2G got fixed to use #pragma GCC visibility. So, we can go ahead and remove all NS_HIDDEN-related code now. This also means that when modifying Android and B2G-specific code that uses symbols imported from other dynamic libraries, you will need to add to config/system-headers (when including system libraries) or add MOZ_EXPORT to the declarations you're importing (e.g. if you're forward-declaring a class name that's defined in a system header). As of now, all uses of NS_HIDDEN and NS_HIDDEN_ have been removed outside of xpcom/. Do not add any more usage outside of xpcom/. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 3:03 PM, Benoit Jacob jacob.benoi...@gmail.com wrote: 2014-06-02 17:13 GMT-04:00 Rik Cabanier caban...@gmail.com: On Mon, Jun 2, 2014 at 11:08 AM, Benoit Jacob jacob.benoi...@gmail.com wrote: 2014-06-02 14:06 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com: 2014-06-02 13:56 GMT-04:00 Nick Alexander nalexan...@mozilla.com: On 2014-06-02, 9:59 AM, Rik Cabanier wrote: On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander nalexan...@mozilla.com mailto:nalexan...@mozilla.com wrote: On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier caban...@gmail.com mailto:caban...@gmail.com wrote: isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? One option would be to make isIdentity and is2D state bits in the object rather than predicates on the matrix coefficients. Then for each matrix operation, we would define how it affects the isIdentity and is2D bits. For example we could say translate(tx, ty, tz)'s result isIdentity if and only if the source matrix isIdentity and tx, ty and tz are all exactly 0.0, and the result is2D if and only if the source matrix is2D and tz is exactly 0.0. With that approach, isIdentity and is2D would be much less sensitive to precision issues. In particular they'd be independent of the precision used to compute and store store matrix elements, which would be helpful I think. I agree that most mathematical ways of determining a matrix (as a rotation, or a translation, etc) come with isIdentity for free; but are most matrices derived from some underlying transformation, or are they given as a list of coefficients? You can do it either way. Here are the constructors: http://dev.w3.org/fxtf/geometry/#dom-dommatrix-dommatrix So you can do: var m = new DOMMatrix(); // identity = true, 2d = true var m = new DOMMatrix(translate(20 20) scale(4 4) skewX); // identity = depends, 2d = depends var m = new DOMMatrix(otherdommatrix; // identity = inherited, 2d = inherited var m = new DOMMatrix([a b c d e f]); // identity = depends, 2d = true var m = new DOMMatrix([m11 m12... m44]); // identity = depends, 2d = depends If the latter, the isIdentity flag needs to be determined by the constructor, or fed as a parameter. Exactly how does the constructor determine the parameter? Exactly how does the user? The constructor would check the incoming parameters as defined: http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-is2d http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity Thanks for providing these references. As an aside -- it worries me that these are defined rather differently: is2d says are equal to 0, while isIdentity says are '0'. Is this a syntactic or a semantic difference? But, to the point, the idea of carrying around the isIdentity flag is looking bad, because we either have that A*A.inverse() will never have isIdentity() == true; or we promote the idiom that to check for identity, one always creates a new DOMMatrix, so that the constructor determines isIdentity, and then we query it. This is no better than just having isIdentity do the (badly-rounded) check. The way that propagating an is identity flag is better than determining that from the matrix coefficients, is that it's predictable. People are going to have matrices that are the result of various arithmetic operations, that are close to identity but most of the time not exactly identity. On these matrices, I would like isIdentity() to consistently return false, instead of returning false 99.99% of the time and then suddenly accidentally returning true when a little miracle happens and a matrix happens to be exactly identity. ...but, to not lose sight of what I really want: I am still not convinced that we should have a isIdentity() method at all, and by default I would prefer no such method to exist. I was only saying the above _if_ we must have a isIdentity method. Scanning through the mozilla codebase, IsIdentity is used to make decisions if objects were transformed. This seems to match how we use Identity() internally. Since this seems useful for native applications, there's no reason why this wouldn't be the case for the web platform (aka blink's rational web platform principle). If for some reason the author *really* wants to know if the matrix is identity, he can calculate it manually. I would be fine with keeping this as an internal flag and defining
Re: Standardized assertion methods
On 2014-06-02, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than it looks better to me? I personally think consistency trumps any personal preferences based on length/concision, as long as what we end up with isn't unreasonably long/verbose. I have two reasons: 1. I believe verbosity for test assertion functions is a bad thing. is/ok are easier to type/read than the Assert.jsm types. I assume that people familiar with CommonJS (which Assert.jsm seems to be based on) would perhaps be trained to ignore the verbosity of those functions, but people who write mochitest-chrome tests very frequently would probably not fall into that category. 2. I also value consistency more than my personal preferences, and based on that, using the existing APIs in some tests and the new APIs in other tests (even if we agreed that #1 above doesn't matter) is strictly worse than the status quo. Also, I'm not sure where the original discussion happened, and what the reasons are, but if the goal is to be more consistent, it seems like we need to move xpcshell tests to use the SimpleTest APIs since that seems to be the only test framework that we have which currently doesn't use it (ignoring testharness.js of course, and reftests don't really have an assertion API). I don't think adding a third (fourth considering th.js) and trying to transition mochitest-browser/chrome to it gradually gets us close to that goal. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/14, 3:42 PM, Ehsan Akhgari wrote: 2. I also value consistency more than my personal preferences, and based on that, using the existing APIs in some tests and the new APIs in other tests (even if we agreed that #1 above doesn't matter) is strictly worse than the status quo. btw, in the mozilla.dev.tech.javascript-engine.internals fork of this thread, bz and David Bruant pointed out that W3C's testharness and TC39's test262 each use yet another set of assertion function names. Any tests we import from those test suites will need glue code to integrate with our test harness(es). chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 2014-06-02, at 16:24, Chris Peterson cpeter...@mozilla.com wrote: btw, in the mozilla.dev.tech.javascript-engine.internals fork of this thread, bz and David Bruant pointed out that W3C's testharness and TC39's test262 each use yet another set of assertion function names. Any tests we import from those test suites will need glue code to integrate with our test harness(es). Sounds like an area ripe for standardisation…I mean bike-shedding. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: xpcom supported
Thank you i see no messages indicating whether it loaded in browser console
this simply means that its not getting picked up?
are these correct configurations ?
chrome.manifest
---
content helloworld content/
resource helloworld content/
interfaces components/MyComponent.xpt
binary-component components/MyComponent.so ABI=Linux_x86-gcc3
install.rdf
-
?xml version=1.0?
RDF xmlns=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
xmlns:em=http://www.mozilla.org/2004/em-rdf#;
Description about=urn:mozilla:install-manifest
em:idhellowo...@mozilla.doslash.org/em:id
em:version1.0/em:version
em:unpacktrue/em:unpack
em:type2/em:type
!-- Firefox --
em:targetApplication
Description
em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id
em:minVersion3.6/em:minVersion
em:maxVersion99.*/em:maxVersion
/Description
/em:targetApplication
!-- optional items --
em:nameHello World extension for Firefox/em:name
em:descriptionDemo extension./em:description
em:creatorXXX/em:creator
em:homepageURLhttp://www.yahoo.com/em:homepageURL
/Description
/RDF
components folder has xpt and so file.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: xpcom supported
in above code i get exception Components.classes not defined.
when i try to put simple code in the html file ( loaded via a menu option of
the extension )
try {
var Cc = Components.classes[@amazon.com/MyComponent;1];
alert(Cc + Cc);
}
catch (errr){
alert(errr)
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/14, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than it looks better to me? My personal experience is that when I try to write xpcshell tests the amount of time it takes to type the test function names is very noticeable and actively interrupts my thinking about what I actually want to test... I find it much simpler to write mochitests than xpcshell tests for this reason. I'm quite willing to believe this is not the case for everyone else, of course. I personally think consistency trumps any personal preferences based on length/concision Of course given the existence of testharness we're not going to get consistency in mochitest anyway, even with this change. as long as what we end up with isn't unreasonably long/verbose. I think what xpcshell has now and what testharness says and what's being proposed (with the Assert. prefix) are unreasonably long/verbose. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/14, 7:26 PM, Martin Thomson wrote: Sounds like an area ripe for standardisation Note that standardizing several test suites on the same API might not work all that well when they have different goals and operating parameters, because what can you end up with is an API that doesn't quite fit any of them very well... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 6/2/14, 9:44 PM, Boris Zbarsky wrote: On 6/2/14, 7:26 PM, Martin Thomson wrote: Sounds like an area ripe for standardisation Note that standardizing several test suites on the same API might not work all that well when they have different goals and operating parameters Specifically, testharness and xpcshell are the ones I'm thinking about here. Mochitest is somewhere in between. The proposed API would work fine for mochitest and xpcshell, but not for testharness. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
Off the top of my head, the places in Gecko I know of that use isIdentity or is2D fall into two categories: 1) math performance optimizations 2) (is2D only) we're going to take an implementation approach that only works for 2D affine transforms, and either a) there is no support for 3D perspective transforms at all, or b) that support is implemented very differently (e.g. transforming Bezier control points vs rendering to a bitmap and applying 3D transform to that). For category #1 we can perhaps avoid having Web developers call isIdentity/is2D, by optimizing internally. We simply haven't bothered to do those optimizations in Gecko matrix classes, we let the callers do it (but perhaps we should reconsider that). For category #2, I can't see a way around exposing is2D to the Web in some form. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Mon, Jun 2, 2014 at 7:07 PM, Robert O'Callahan rob...@ocallahan.org wrote: Off the top of my head, the places in Gecko I know of that use isIdentity or is2D fall into two categories: 1) math performance optimizations 2) (is2D only) we're going to take an implementation approach that only works for 2D affine transforms, and either a) there is no support for 3D perspective transforms at all, or b) that support is implemented very differently (e.g. transforming Bezier control points vs rendering to a bitmap and applying 3D transform to that). For category #1 we can perhaps avoid having Web developers call isIdentity/is2D, by optimizing internally. We simply haven't bothered to do those optimizations in Gecko matrix classes, we let the callers do it (but perhaps we should reconsider that). Yes, isIdentity is used as an indication that nothing needs to be done or that the transform hasn't changed. Maybe we should rename it to isDefault, isInitial or isNoOp? For category #2, I can't see a way around exposing is2D to the Web in some form. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
To recap I think the following points have been resolved: - remove determinant (unless someone comes up with a strong use case) - change is2D() so it's a flag instead of calculated on the fly - change isIdentity() so it's a flag. - update constructors so they set/copy the flags appropriately Still up for discussion: - rename isIdentity - come up with better way for the in-place transformations as opposed to by - is premultiply needed? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
Minor spec suggestion: This looks like a great primitive, but having to create GC pressure to multiply values by the matrix seems like a real mistake. transformPoint should have an overload that accepts a Float64Array and mutates it in-place, or maybe a 'in, out' pair of arrays. Probably also accept offsets into each array so that you can use it to transform a series of points by the matrix (a fairly common graphics/geometry operation). On Mon, Jun 2, 2014 at 8:32 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jun 3, 2014 at 3:28 PM, Rik Cabanier caban...@gmail.com wrote: Yes, isIdentity is used as an indication that nothing needs to be done or that the transform hasn't changed. Maybe we should rename it to isDefault, isInitial or isNoOp? I think isIdentity is the right name. Glancing through Gecko I see places where we're able to entirely skip possibly-expensive transformation steps if we have an identity matrix, so I guess isIdentity is useful to have since even if we make multiplication-by-identity free, checking isIdentity might mean you can completely avoid traversing some application data structure. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ 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: DOMMatrix
On Mon, Jun 2, 2014 at 8:32 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Tue, Jun 3, 2014 at 3:28 PM, Rik Cabanier caban...@gmail.com wrote:
Yes, isIdentity is used as an indication that nothing needs to be done or
that the transform hasn't changed.
Maybe we should rename it to isDefault, isInitial or isNoOp?
I think isIdentity is the right name.
Glancing through Gecko I see places where we're able to entirely skip
possibly-expensive transformation steps if we have an identity matrix, so I
guess isIdentity is useful to have since even if we make
multiplication-by-identity free, checking isIdentity might mean you can
completely avoid traversing some application data structure.
Yes, that's what I'm seeing in WebKit and Blink as well.
For instance:
const AffineTransform transform = context-getCTM();
if (m_shadowsIgnoreTransforms !transform.isIdentity()) {
FloatQuad transformedPolygon =
transform.mapQuad(FloatQuad(shadowedRect));
transformedPolygon.move(m_offset);
layerRect =
transform.inverse().mapQuad(transformedPolygon).boundingBox();
} else {
layerRect = shadowedRect;
layerRect.move(m_offset);
}
and:
if (!currentTransform.isIdentity()) {
FloatPoint3D absoluteAnchorPoint(anchorPoint());
absoluteAnchorPoint.scale(size().width(), size().height(), 1);
transform.translate3d(absoluteAnchorPoint.x(),
absoluteAnchorPoint.y(), absoluteAnchorPoint.z());
transform.multiply(currentTransform);
transform.translate3d(-absoluteAnchorPoint.x(),
-absoluteAnchorPoint.y(), -absoluteAnchorPoint.z());
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
