Bug 78971

Created attachment 127711 [details] Patch

I am not clear on how an embedder would make this decision or why they would want anything but the default.

Right now, using a backing store larger than 1:1 has issues, at least on the Chromium port, which are captured at https://bugs.webkit.org/show_bug.cgi?id=73645 . On the desktop, the deviceScaleFactor is 1 anyway, so we don't see these issues. However, on a high-dpi mobile system the deviceScaleFactor can be 2, which is where these issues would be seen. iOS 5.0 WebKit hard codes the backing store to be 1:1, perhaps for the same reasons. See the initialisation of m_pageScaleFactor to 1 in the constructor of HTMLCanvasElement.cpp http://opensource.apple.com/source/WebCore/WebCore-1298/html/HTMLCanvasElement.cpp Fixing the issues relating to high-dpi is a longer term project, so in the mean time it is desirable to be able to have a correctly functioning canvas (according to the spec and tests). Another aspect of this is that many web developers typically do not expect a difference between backing store and specified canvas dimensions, despite the spec allowing this. When converting the canvas to a data url, for example, many developers expect that the size of the image will be according to the canvas dimensions, rather than the backing store dimensions (See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15041 )

(In reply to comment #3) > Right now, using a backing store larger than 1:1 has issues, at least on the Chromium port, which are captured at https://bugs.webkit.org/show_bug.cgi?id=73645 . On the desktop, the deviceScaleFactor is 1 anyway, so we don't see these issues. However, on a high-dpi mobile system the deviceScaleFactor can be 2, which is where these issues would be seen. > > iOS 5.0 WebKit hard codes the backing store to be 1:1, perhaps for the same reasons. See the initialisation of m_pageScaleFactor to 1 in the constructor of HTMLCanvasElement.cpp http://opensource.apple.com/source/WebCore/WebCore-1298/html/HTMLCanvasElement.cpp > > Fixing the issues relating to high-dpi is a longer term project, so in the mean time it is desirable to be able to have a correctly functioning canvas (according to the spec and tests). > > Another aspect of this is that many web developers typically do not expect a difference between backing store and specified canvas dimensions, despite the spec allowing this. When converting the canvas to a data url, for example, many developers expect that the size of the image will be according to the canvas dimensions, rather than the backing store dimensions (See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15041 ) Ok, so on what port would you want non 1:1? This change seems to only create the possibility for more incompatibilities between different ports of WebKit which should be avoided.

I think that for now, probably all ports should use 1:1, however, it would be helpful for the fixing of 73645 if there was an easy way to switch back to the 'high-dpi' backing canvas. It sounds like a WebCore setting may not be the best way to do this. Would a ENABLE(HIGH_DPI_CANVAS) option be better here, do you think?

(In reply to comment #5) > I think that for now, probably all ports should use 1:1, however, it would be helpful for the fixing of 73645 if there was an easy way to switch back to the 'high-dpi' backing canvas. > > It sounds like a WebCore setting may not be the best way to do this. Would a ENABLE(HIGH_DPI_CANVAS) option be better here, do you think? Yes.

Created attachment 127742 [details] Patch

Comment on attachment 127742 [details] Patch Clearing flags on attachment: 127742 Committed r108293: <http://trac.webkit.org/changeset/108293>

All reviewed patches have been landed. Closing bug.