| 00:40 | <MikeSmith> | jpwhiting: I guess you figured out by now that if you delete those copied files, the build will re create them from the sources |
| 00:40 | <MikeSmith> | so you might just wasn |
| 00:41 | <MikeSmith> | might just want to have your package build have a prep step that deletes that whole tree |
| 01:21 | <jpwhiting> | MikeSmith: yep, and since that libsetuid.so isn't even used I just deleted it, np |
| 01:34 | <MikeSmith> | jpwhiting: ok, great |
| 02:33 | <MikeSmith> | jpwhiting: btw, about minimum jdk version, I think its java 5. I don't think we have any 6 isms in there |
| 09:04 | <SimonSapin> | what should UAs do when encountering multiple <title> elements? I don’t find it in the spec |
| 09:05 | <SimonSapin> | Same question for <meta> elements with the same name |
| 09:05 | <Ms2ger> | Put them into the DOM |
| 09:07 | <Ms2ger> | If you mean what should be shown in the UI... |
| 09:07 | <Ms2ger> | "The string to use as the document's title is given by the document.title IDL attribute." |
| 09:07 | <Ms2ger> | " |
| 09:07 | <Ms2ger> | User agents should use the document's title when referring to the document in their user interface. When the contents of a title element are used in this way, the directionality of that title element should be used to set the directionality of the document's title in the user interface." |
| 09:07 | <SimonSapin> | found it: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-title-element-0 |
| 09:07 | <SimonSapin> | use the first |
| 09:08 | <SimonSapin> | I meant as opposed to use the last, or ignore them all, or something |
| 09:10 | <Ms2ger> | That all depends on what you need it for |
| 09:11 | <SimonSapin> | write it in the corresponding PDF metadata … or if you consider WeasyPrint together with a PDF viewer, show it in the UI |
| 13:29 | <galant> | Hickson here? |
| 13:38 | <galant> | is there array for all canvases on webpage? |
| 13:39 | <Philip`> | galant: document.getElementsByTagName("canvas") |
| 13:39 | <galant> | ah ye |
| 13:40 | <galant> | :) thanks man - too much work my mind is blocked :) |
| 13:50 | <galant> | how much zoom needs for element to go out of screen> |
| 15:52 | <galant> | guys |
| 15:53 | <galant> | anyone here to help me? |
| 15:53 | <galant> | can I save pixels from canvas and change them with imagedata? |
| 23:49 | <annevk> | cabanier: yo, so the general canvas for worker design is generally agreed upon? |
| 23:52 | <cabanier> | annevk: I don't think so |
| 23:52 | <cabanier> | annevk: I haven't seen any feedback |
| 23:52 | <annevk> | cabanier: hmm yeah, I guess that indicates it's not |
| 23:53 | <cabanier> | annevk: I can't tell how it's supposed to work. how can the drawing in the worker synchronize with the main thread? |
| 23:53 | <cabanier> | annevk: I have seen negative feedback for webgl in a worker |
| 23:54 | <annevk> | cabanier: using commit() I think |
| 23:54 | <cabanier> | "Having designed several rendering engines that used GL share groups in the past, I can say that WebGL in a worker alone is not what most people want (though they don't know that, yet). The additional latency of moving input events to the background thread (we all aren't just spinning cubes, you know) and the inability to properly synchronize DOM elements makes primary rendering in a worker a non-starter in most cases, and in others just makes it signif |
| 23:55 | <cabanier> | annevk: When would you call commit? there's no requestanimationFrame in a worker... |
| 23:55 | <annevk> | Similar concerns have been raised about Web Audio... Latency :/ |
| 23:55 | <zewt> | ... the main use case for webgl in workers are doing offscreen rendering and math, not rendering for display |
| 23:56 | <zewt> | (not impressed by people who tell me "i know more than you and you'll realize it some day") |
| 23:56 | <cabanier> | zewt: will that speed up things though? |
| 23:57 | <zewt> | the point of workers is to keep stuff from hitching the ui more than speeding anything up |
| 23:57 | <cabanier> | zewt: in the non-web platform world, few applications have pulled this off. |
| 23:57 | <cabanier> | zewt: wouldn't asynchronous API solve that too? |
| 23:57 | <zewt> | in a clumsier way, sometimes |
| 23:58 | <zewt> | (opengl isn't a nicely controllable asynchronous api, so it's probably not a good fit) |
| 23:58 | <cabanier> | zewt: yeah. most (all?) canvas 2d implementors are on top of OpenGL or DirectX so have the same problem |
| 23:59 | <zewt> | and on mobile you're generally stuck with whatever native gles you've got |