[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL support for high bit depth rendering & display
On Fri, Sep 21, 2012 at 8:03 PM, Matt McLin <firstname.lastname@example.org>
I have no doubt that more than 8-bpc is great. But as has repeatedly been said, it's not easy to do inside an app that hosts other apps inside itself, that host content, which might require it, that is a pipeline/compositor all by itself, that needs not only satisfy this usecase, but others, and hardware that can't do what you ask for. So we also can't just replace any code, there's got to be flexibility towards the pixel format, and consistency, something that's entirely unplanned for and hard to do for anybody without such a rig.
Hi Florian, I agree with everything you said. Certainly anyone interested in implementing support for >8-bits per channel should have a suitable rig to display/validate it. But none of this is news to me, and as for easy vs. hard, well I think it's our job to solve hard problems. :) And more often than not, it's just a sign that the problem needs to be broken down & approached in a slightly different way. Unfortunately, I don't have the time/capacity to devote myself to improving browser code at this time, so I'm just hoping to inspire some forward-looking ideas for those that do.
Technical question on this browser pipeline -- specifically with respect to WebGL, is the WebGL backbuffer presented/copied/swapped directly to the display's frontbuffer (or backbuffer in the case of OS with it's own composition pipeline, such as Microsoft's DWM)? If not, through how many other buffers is it copied before it gets there? Does anyone know if this pipeline differs much for Chrome vs. Firefox?
WebGL content is composited with other elements in the page, it's not presented directly to a backbuffer. In Chrome, there will be several intermediate steps. First, if the WebGL context has the antialias context attribute set to true (which is the default in Chrome) we'll resolve from the multisampled renderbuffer backing the context into a texture. If the preserveDrawingBuffer attribute is set to true (which isn't the default) we'll do a texture copy. Then we'll composite this texture with the rest of the elements on the page. This may involve rendering into one or more intermediate framebuffers in order to apply effects like CSS masks which can apply to WebGL's output. Where this composited output for a page goes depends on the platform and OS version. On some platforms we composite this output with the rest of the browser UI and then present that to either the display or to the native window system. On others, we present just the web page's content to a native window system window and let that system (DWM, X11, AppKit or whatnot) composite that with the rest of the windows in the system to the display.
I'm not personally familiar with Firefox's system but I understand it is similar. To support 30bit color output for WebGL we would have to either make the entire pipeline aware of this format up to and including the OS integration or define a way for this content to punch just the WebGL output through directly to the display. Both would be a fair amount of work to hook up but not impossible.