- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Aug 2017 11:40:33 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `Consider adding property for expected rendered bitmap size.`, and agreed to the following resolutions: * `RESOLVED: Add devicePixelRatio to canvasContext, other MQs can be accessed via custom properties` <details><summary>The full IRC log of that discussion</summary> <flackr> Topic: Consider adding property for expected rendered bitmap size.<br> <flackr> Github: https://github.com/w3c/css-houdini-drafts/issues/436<br> <fantasai> flackr: So for supporting high-DPI displays or scenarios where you're drawing to somehting rastered at a smaler scale or higher cuz zoomed in<br> <fantasai> flackr: Might b useful to devs to know what final size will be<br> <fantasai> flackr: So can make decisions about how much detail to draw, or how thin hairlines should be<br> <fantasai> flackr: There was something on canvas context called rasterBackingScale, never fully standardized<br> <fantasai> iank_: Shipped in Safari at one point<br> <fantasai> flackr: matched device scale ration<br> <fantasai> s/ration/ration<br> <fantasai> s/ration/ratio<br> <fantasai> flackr: having this would let developer make decisions about quality, maybe pick faster paths for thumbnail-size image<br> <fantasai> flackr: Wouldn't have to give dev the final one, could just be an approximation<br> <fantasai> flackr: increase cache coherency by caching just a few sets o fdisplay lists<br> <fantasai> nical: Does this mean you invalidate paint every time you zoom?<br> <fantasai> flackr: You don't give true value, could just use a threshold<br> <fantasai> iank_: What we noticed is that everything inside the Paint API is in CSS pixels<br> <fantasai> iank_: We had people internally tyring to draw borders and couldn't get the alignment right, wanted to be *on* physical pixels<br> <fantasai> iank_: For a lot of cases this isn't an issue, but doing border type stuff it is<br> <fantasai> flackr: So could be an additional value on canvasContext, could be another value on paint context<br> <fantasai> dino: Is there a re that UA ivnalidate at some point?<br> <dino> s/dino/dbaron/<br> <fantasai> dino: I guess I'm thinking about if a UA might want to use to back their canvas by a buffer of drawing commands rathe than a bitmap, might be less need to rerasterize as you scale<br> <dino> s/dino/dbaron/<br> <fantasai> dbaron: But might end up with web depending on the fact that theres rerasterizing every so often<br> <fantasai> dbaron: because ppl are tyring to draw device px -sized borders<br> <fantasai> dbaron: Would be hard to switch to graphics commands that have no need ot rereasterize<br> <fantasai> dbaron: Maybe detec whether this property has access, rerasterize as needed<br> <fantasai> iank_: Also could request with a settings flag, I would like to know what hte backing style is<br> <dbaron> fantasai: A little concerned if you have access to this only in this API and not elsewhere<br> <dbaron> fantasai: e.g., media queries, you'd want this information for showing detail on an SVG. That's been brought up.<br> <dbaron> fantasai: If you can do that in paint worklet but not declaratively in SVG<br> <dbaron> iank_: not an issue for canvas today because people typcilaly inspect the devicePixelRatio property on window<br> <dbaron> fantasai: doesn't respond to zoom<br> <dbaron> flackr: this would have to (?)<br> <dbaron> fantasai: it responds to layout-effecting zoom, but not graphical zoom<br> <flackr> s/would/doesn't necessarily<br> <dbaron> dino: You couldn't get this (hairline) through normal CSS -- why do you want to add it here?<br> <fantasai> flackr: Where this comes up is we take the CSS sizies and align them to pixel boundaries in some of our rasterization code<br> <fantasai> flackr: But as a developer, i fyou're writing custom paint for this thing, we don't know if you want to draw between pixel boundaries or do you want to snap to pixel boundaries<br> <fantasai> dino: I would sort of think, too bad, you've gone to this API with custom drawing. You custom draw, you don't get the smarts of the browser.<br> <fantasai> flackr: But then custom drawn stuff is inferior to the browser<br> <fantasai> dino: It's inferior because you have less knowledge fo the context<br> <fantasai> dino: You don't get htis with canvas<br> <fantasai> flackr: You can do it in canvas already<br> <fantasai> fantasai: browser zoom<br> <fantasai> flackr: Assume we do this only for layout zoom, then, not for browser zoom<br> <fantasai> dino: Then why not query the device-pixel-ratio?<br> <fantasai> dino: I'd be fine with exposing that<br> <fantasai> dino: I'd be concerned about exposing rasterization<br> <fantasai> dino: Sometimes not needed to rasterize<br> <fantasai> dino: Let's just expose device-pixel-ratio<br> <fantasai> iank_: I'd e ok with that<br> <fantasai> dino: Now suppose you always snap corner of canvas to pixel boundaries<br> <fantasai> dino: Not going to be undone by their own smarts if browser is doing something smart<br> <fantasai> dino: So what's the euqivalent window n worklet?<br> <fantasai> flackr: So this solves the common case, rendering on high DPI device nicely<br> <fantasai> flackr: May not matte,r but doens't solve case of layout size being changed by some ancestor scale<br> <fantasai> Myles_: Regular canvas already has that problem<br> <fantasai> flackr: I think that's probably fine<br> <fantasai> iank_: So we'll need to work out what the best API is, either pass as additional argument maybe among paint size object / ocntext<br> <fantasai> iank_: or we could put it on the paint worklet global scope<br> <fantasai> iank_: window.devicePixelRatio<br> <fantasai> iank_: Iwht req that when this value changes, they need to rerun all the paint functions<br> <fantasai> flackr: Not sure you need that requirement<br> <fantasai> Emil: MOve to different screne, might lose quality<br> <fantasai> dino: At that point you're painting again anyway<br> <fantasai> dino: Don't need to spec that req, because you're invlidating<br> <eae> s/Emil/eae/<br> <fantasai> iank_: Is a bit backwards from [canvas?]<br> <fantasai> iank_: You create a canvas bigger than native size and then scale it down<br> <fantasai> dino: You say cavas widht is CSSStyleWidthx devicePixelRatio<br> <fantasai> iank_: So maybe say give me the canvas scaled up to the device pixel ratio instead?<br> <fantasai> dino: They have to do the scale manually<br> <fantasai> iank_: We gie them the canvas in CSS Pixels<br> <fantasai> dino: And usually people multiple canvas by devicePixelRatio to get device pixel-sized canvas<br> <fantasai> iank_: So maybe we should give a flag that gives them the device pixel sized cavnas<br> <fantasai> eae: Why not use device pixel by default?<br> <fantasai> iank_: People like drawing in CSS pixel space, because odn't get something weirdly small by default on highDPI devices<br> <fantasai> ...<br> <fantasai> dino: If you want to talk in small pixels...<br> <fantasai> dino: When you start painting, you assume you draw in CSS pixel land, and when you want to draw at device pixels you scale by DPR<br> <fantasai> dino: ...<br> <fantasai> iank_: concerned about JS downscaling<br> <fantasai> iank_: Dino was asking why not always use CSS px and devs use DPR<br> <fantasai> iank_: My concern was about introducing rounding errors<br> <fantasai> dino: DPR is in the range of .5 to 10, so not a huge range of rounding<br> <fantasai> Myles_: When you multiply float by 2 or half or something, you're fine. You'd hav eto have really big numbers before you start having errors on the order of a pixel<br> <fantasai> iank_: Your version is you get a bitmap in CSS szie, so you scale 1/r and I was saying we give it to you in the device pixel size<br> <fantasai> dino: I think mine makes sense because i fyou were doing in canvas land, you'd get CSS pixels<br> <fantasai> dino: You'd have to be explicit and say I want more pixels<br> <fantasai> iank_: My version matches cavasland a bit, because that's implicitly what we do<br> <fantasai> iank_: Get the canvas in a larger size<br> <fantasai> ...<br> <fantasai> iank_: You say explicitly, I want device pixels if this boolean is true<br> <fantasai> iank_: and the canvas is larger by the DPR<br> <fantasai> dino: Are you actually making a mapping store for this?<br> <fantasai> dino: You're not actually creating a backing store, syaing that .5px will give author a solid hairline<br> <fantasai> dino: If iI'm at DPR=2, I can be pretty sure that .5px will be a hariline<br> <fantasai> [...]<br> <fantasai> Rossen: All of these paitns are pre-transform paints<br> <fantasai> Rossen: Going back to original motivation, you were talking about when you zoom and you have transforms etc<br> <fantasai> Rossen: Was concerned you were trying thandle level of detail for different optical scaling<br> <fantasai> Rossen: Although this is a noble goal, I think it's going to be very tricky to get right<br> <fantasai> Rossen: Especially offsetting this to paint API<br> <fantasai> Rossen: But when the problem resovled down to just accounding for dpi, that's fine<br> <fantasai> Rossen: I think that would be enough, and the hairline would resolve<br> <fantasai> Rossen: I think overall if we only gave DPR it's fine<br> <fantasai> iank_: Preference on exposing this as downscaling or upscaling?<br> <fantasai> dino: It would be really weird if your custom paint was a 1-line "fill the entire box", you have to scale it by two.<br> <fantasai> dino: You should just say "fill the box"<br> <fantasai> dino: If you explicitly ask for the DPR<br> <fantasai> dino: Why would you want every bit of code to put context.scale<br> <fantasai> ?<br> <fantasai> dino: Context is the same every frame, don't need to do it each time<br> <fantasai> iank_: It's the same numbe ro flines of code each way<br> <fantasai> iank_: Does someone else have an opinion?<br> <fantasai> dino: Would be weird to say "this is what you have to do in every paint"<br> <fantasai> dino: If you want to paint a hariline, you need to know, but otherwise don't<br> <fantasai> Rossen: This is why don't want to resolve level of detail<br> <fantasai> Rossen: Keep adding details and additional details, that's very different from<br> <fantasai> Rossen: At the end of the day wnat to draw one pixel line<br> <fantasai> flackr: My fault for filing an overly broad issue<br> <fantasai> flackr: Where it came up was DPR problem<br> <fantasai> flackr: I think it's reasonable to pass that down<br> <fantasai> iank_: We had some bugs with paitning from CSS API, but we can see how this works and do dino's proposal and see how that works<br> <fantasai> q+<br> <fantasai> dino: SO resolution would be, same value for DPR from normal context would be exposed to the paint worklet<br> <fantasai> iank_: Or on the ? or somewhere. TBD.<br> <fantasai> dino: And effectively that's all<br> <fantasai> iank_: Might be better in input, because then invalidation is clearer<br> <fantasai> dino: Not necessarily that it's been invalidated, you're being called to draw again<br> <fantasai> Rossen: If ..., then you don't have to redraw<br> <fantasai> iank_: OK, I'm fine with exposing on global scope<br> <fantasai> flackr: That would be my preference for consistency<br> <fantasai> iank_: Problem with worklets is we don't have a self object<br> <fantasai> iank_: That may be fine<br> <fantasai> iank_: window or self.dpr?<br> <fantasai> iank_: OK, I'll talk it through with myself<br> <fantasai> iank_: I'm fine<br> <fantasai> ack fantasai<br> <dbaron> fantasai: If we're exposing DPR, is that the only MQ we need to expose, or do we need to expose others like color-gamut<br> <fantasai> fantasai: So since we're exposing device-pixel-ratio, are there other media queries that we want to expose here, like color-gamut?<br> <fantasai> dino: On the main thread, would say I want to create a worklet that operates in this color space<br> <Rossen> s/If .../If the device-pixel-ratio is the only thing that changes/<br> <fantasai> iank_: registerPaint, give me this paint worklet function, operates in this color space<br> <fantasai> dino: Maybe that's answer to high contrast, do it at creation time, then need to have a listener in the main thread and invalidate manually? That's maybe okay as well<br> <fantasai> dino: I thin asnwer to fantasai's question is that there's nothing missing, might be odd to tear down the worklet and rebuild with a new MQ value<br> <fantasai> jack: If you drag window from one monitor to another, would nee dot tear down all worklets?<br> <fantasai> dino: Just ht eone affected<br> <fantasai> jack: For DPR it will just happen?<br> <fantasai> dino: ...<br> <fantasai> dino: fantasai's question was about whater other MQ values<br> <fantasai> franremy: set it onto a custom property<br> <fantasai> Myles_: If you drag from one monitor to another, could change color space<br> <fantasai> fantasai: Concern is, if dealing with DPR one way why inconsistent about how to handle other MQs?<br> <fantasai> dino: DPR is special<br> <fantasai> Myles_: All of them will be available, but some will have different lifetimes<br> <fantasai> fantasai: Yes, but why should only one MQ be available to the paint worklet, and the others need to be passed through as arguments and worklets torn down and rebuilt througha listener if they happen to change?<br> <fantasai> iank_: If you wanted to write a paint worklet for device widht, would have to write a lot of listeners and recreate the worklets<br> <fantasai> dino: why would you have a custom paint ...<br> <fantasai> iank_: Can do it with a custom property<br> <fantasai> iank_: The paint worklet is registered to set of properties, will invalidate when one of them changes<br> <fantasai> iank_: So could set the MQs you care about into a custom property that's passed ot the paint worklet<br> <fantasai> franremy: E.g. mgiht want to listen to reduce-motion<br> <fantasai> RESOLVED: Add devicePixelRatio to canvasContext, other MQs can be accessed via custom properties<br> <fantasai> <br type=lunch<br> <fantasai> ><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/436#issuecomment-319346447 using your GitHub account
Received on Tuesday, 1 August 2017 11:40:35 UTC