- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jun 2019 15:53:50 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Opaque font P&V type for PaintWorklet font rendering`, and agreed to the following: * `RESOLVED: disable svg text when in a paint worklet, possibly falling back to svg native` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: Opaque font P&V type for PaintWorklet font rendering<br> <Rossen_> github: https://github.com/w3c/css-houdini-drafts/issues/899<br> <emilio> flackr: So while experimenting with PaintWorklet I decided to use fonts and the general idea seems to be that we avoid everything that relies on the document data<br> <heycam> q+<br> <emilio> ... I wonder if we could expose a font type so that we could resolve the font on the main thread and pass it down to the paint worklet<br> <emilio> bkardell_: so like a transferable font?<br> <AmeliaBR> q+<br> <emilio> flackr: I'd expect it to be more like an <image> type<br> <emilio> ... I don't expect to be able to do anything with it other than drawing<br> <emilio> myles: why not just passing a string?<br> <emilio> flackr: because that requires going through the platform code<br> <emilio> myles: should just be thread-safe<br> <emilio> TabAtkins: we disallow parsers on the worklet<br> <emilio> ... Chromium's css parser is not thread-safe<br> <emilio> myles: I'd be hesitant to add more API surface until there's more investigation<br> <emilio> iank_: you have a side-channel, you don't know if that font is loaded<br> <emilio> myles: I thought these weren't supposed to have any document data<br> <heycam> emilio: the fact that Chromium's CSS parser is not thread safe is a Chromium limitation<br> <emilio> myles: you want @font-face then this problem is really hard<br> <emilio> flackr: limiting it to system font limits the use cases<br> <emilio> myles: I think it'd be a good start<br> <emilio> TabAtkins: if we want to do font-face you could be able to send fontface objects<br> <emilio> myles: and no fallback/<br> <emilio> *?<br> <emilio> TabAtkins: you can do it yourself<br> <emilio> myles: that's not great<br> <emilio> TabAtkins: or send an array<br> <Rossen_> q?<br> <bkardell_> s/*?bkardell: can you not just transfer the array of resolved fonts?<br> <emilio> myles: I think we can choose between two worlds, on where you (maybe temporarily) only have access to system fonts, and one where the worklet is associated with a document and they share the same loading context and there's no need to transfer anything<br> <myles> s/system/installed/<br> <AmeliaBR> s/*?/bkardell: can you not just transfer the array of resolved fonts?/<br> <AmeliaBR> s/s\/*?bkardell: can you not just transfer the array of resolved fonts?//<br> <Rossen_> ack heycam<br> <emilio> heycam: I was going to ask with the relationship with the font loading api, but if for now there's only going to be installed fonts<br> <emilio> ... If we decide we want font-face i think we may want to not tie it to the document, and the document would have the same FontFaceSet<br> <emilio> hober: Wouldn't that require sync access from the worklet?<br> <hober> s/sync/network/<br> <emilio> heycam: if you want all the font types in the doc then sure, but we could limit it for blobs and array buffers and such<br> <emilio> [missed]<br> <emilio> heycam: you can have svg images with text in it<br> <emilio> myles: but that's not the same, no subpixel AA, etc.<br> <emilio> TabAtkins: we cannot avoid putting text on worklets at some point<br> <dbaron> heycam was talking about <svg:text><br> <emilio> AmeliaBR: svg images has similar restrictions where there are no font-faces and such and it's isolated from the main document rendering<br> <emilio> ... in a way it's not that much different from how paint() is supposed to work<br> <emilio> ... if we have the same restrictions on the paint worklet so that it it can define a font-face where it doesn't have network access<br> <TabAtkins> q+<br> <emilio> ... so it is not as different as <text> in an svg image<br> <emilio> ... whether that addresses authoring use-cases is another question<br> <Rossen_> ack AmeliaBR<br> <emilio> ... saying that it can only use installed fonts doesn't seem aligned with paint()<br> <emilio> ... paint is for graphical effects so you want to have control over the fonts you're drawing<br> <bkardell_> AmeliaBR: is better articulating the question I was attempting to ask myles earlier about the use case -- for paint<br> <emilio> ... if you want textual content it shouldn't be using paint() but be content instead<br> <emilio> ... the proposal that flackr made was adding a new typed om type for fonts<br> <emilio> ... which i think it's a sensible thing for typed om to be able to represent<br> <emilio> ... we could set that from canvas as well<br> <emilio> ... some other people were talking about FontFace object, but fonts is much more complicated, it's a list of fonts with fallback, etc.<br> <emilio> ... we should aim for typed om to be able to represent all CSS data types like the font shorthand<br> <emilio> ... but that's a different question from text in canvas in paint()<br> <emilio> ... i'm not sure where in the cycle we'd prevent you from using constructed typed om objects constructed in the worklet<br> <emilio> ... seems like Chromium's parser is a limitation for chrome but others disagreed<br> <emilio> iank_: that part of the parser may be thread-safe already<br> <Rossen_> q?<br> <Rossen_> ack TabAtkins<br> <emilio> TabAtkins: so a multi-part proposal, I think we can do immediately, given that you can put <svg:text>, I think we could add a canvas function to render svg text<br> <emilio> ... you can create an svg text in the worklet right?<br> <emilio> TabAtkins: so proposal is adding back drawText() to canvas<br> <astearns> s/so proposal/so part 1 of the proposal/<br> <emilio> ... second part of the proposal is that we should see if parsing font stuff is still a problem for browsers (particularly chrome), and if it is figuring out something for that in the short term<br> <heycam> q+<br> <emilio> ... if it's not then probably just expose it and reconsider the decisions<br> <emilio> ... about exposing parser things in the canvas<br> <emilio> iank_: I think that's already thread-safe in blink<br> <emilio> TabAtkins: font stuff in particular?<br> <emilio> iank_: yes<br> <emilio> TabAtkins: part three is: in the medium term we investigate how to expose web fonts<br> <emilio> ... hober's idea about explicitly telling the worklet what fonts to is may work<br> <emilio> myles_: another idea is making FontFaceSet transferrable<br> <emilio> TabAtkins: you still need a way to thread-that down, but that could be a way<br> <emilio> dbaron: I don't recall why we decide text stuff to not be in there?<br> <AmeliaBR> FYI, working demo of text in a Paint worklet, using WebGL: https://github.com/AdaRoseCannon/three-paint<br> <emilio> TabAtkins: it was a philosophical reason, we didn't want people to do a bunch of text stuff in paint worklet<br> <emilio> Rossen_: also we wanted to look how the measuring APIs would work<br> <emilio> ... before doing that<br> <emilio> dbaron: I do recall some system libraries not being thread-safe<br> <emilio> myles_: coretext is not thread-safe, we'd have to rewrite it and that's fine probably<br> <emilio> dbaron: we're on multiple platforms<br> <Rossen_> ack dbaron<br> <TabAtkins> emilio: I think we use mostly harfbuzz these days, and that can be threadsafe<br> <TabAtkins> myles_: CoreText is threadsafe too<br> <myles_> s/coretext/webkit's font handling/<br> <heycam> q-<br> <emilio> dbaron: this makes probably a harder dependency on the idea that paintworklet is a list of drawing commands and not a raster<br> <emilio> TabAtkins: yeah it does<br> <emilio> myles_: why adding drawText if we want to investigate better things in the future?<br> <emilio> TabAtkins: it'd be in canvas2d right?<br> <emilio> myles_: I guess what I'm saying is that the eventual solution may not look like drawText at all<br> <emilio> AmeliaBR: whatever solution should probably be coordinated with canvas api<br> <emilio> myles_: right and we may add a new api to canvas2d<br> <emilio> ... I think it's a bit too early to say that we need to support this API<br> <emilio> TabAtkins: I don't like that there's a hacky way to draw text<br> <emilio> ... but not a good way<br> <emilio> emilio: does the svg stuff _actually_ work?<br> <emilio> TabAtkins: not sure, can somebody confirm quickly that it works?<br> <emilio> TabAtkins: disabling svg text stuff is also a suitable resolution<br> <emilio> iank_: we may be able to do the FontFaceSet stuff<br> <emilio> myles_: I think that's a bad design<br> <emilio> TabAtkins: it also requires network<br> <emilio> heycam: wouldn't you be able to use local sources?<br> <TabAtkins> s/it also requires network/it doesn't give us access to installed fonts/<br> <heycam> q+<br> <emilio> myles_: I think not representing the fact that fonts are a list of fallbacks is doing a disservice to authors<br> <myles_> s/authors/users/<br> <emilio> ... I think we should have transferrable font objects, but they probably shouldn't be FontFace<br> <emilio> ... should be some sort of thin wrapper over what the font shorthand represents<br> <emilio> flackr: I'm hoping that typed om font property can represent that wrapper<br> <emilio> TabAtkins: let's solve this in the medium term so we can all think about this properly<br> <emilio> TabAtkins: I want to resolve whether text is allowed at all or not<br> <emilio> heycam: it's plausible that the svg subsystem doesn't know how to disable svg text in a standalone way<br> <emilio> myles_: svg native doesn't allow text so it may be a good fit for that<br> <emilio> heycam: so you said that the original reason to disallow text is to avoid inaccessible text, is that no longer a concern?<br> <emilio> ... or is it because it works with svg?<br> <emilio> ... because if it's because of the latter we probably don't want to give up<br> <emilio> TabAtkins: it was only one of the factors, others include text is hard, and high-quality text needing font metrics<br> <AmeliaBR> https://ada.is/three-paint/<br> <emilio> AmeliaBR: you could use webgl too, see ^<br> <emilio> myles_: no you can't, you'd need to upload the font as a texture<br> <emilio> TabAtkins: that demo is fake webgl, it's 2d<br> <emilio> ... we cannot really avoid it<br> <emilio> TabAtkins: proposed resolution is to disable text when in a paint worklet, possibly falling back to svg native<br> <emilio> ... and long term we want to lift the text restriction<br> <emilio> AmeliaBR: we could point to the SVG-in-OT restrictions<br> <emilio> RESOLVED: disable svg text when in a paint worklet, possibly falling back to svg native<br> <TabAtkins> s/falling back to/by subsetting to/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/899#issuecomment-499939872 using your GitHub account
Received on Friday, 7 June 2019 15:53:52 UTC