Bug 78971 - Default canvas backing store to be 1:1 with specified dimensions.
Summary: Default canvas backing store to be 1:1 with specified dimensions.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: John Knottenbelt
URL:
Keywords:
Depends on:
Blocks: 66687 78973
  Show dependency treegraph
 
Reported: 2012-02-18 12:52 PST by John Knottenbelt
Modified: 2012-02-22 09:36 PST (History)
8 users (show)

See Also:


Attachments
Patch (5.18 KB, patch)
2012-02-18 13:00 PST, John Knottenbelt
no flags Details | Formatted Diff | Diff
Patch (2.16 KB, patch)
2012-02-19 14:25 PST, John Knottenbelt
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Knottenbelt 2012-02-18 12:52:08 PST
Introduce WebCore Setting for Canvas Backing Store
Comment 1 John Knottenbelt 2012-02-18 13:00:56 PST
Created attachment 127711 [details]
Patch
Comment 2 Sam Weinig 2012-02-18 17:30:51 PST
I am not clear on how an embedder would make this decision or why they would want anything but the default.
Comment 3 John Knottenbelt 2012-02-19 08:40:52 PST
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 )
Comment 4 Sam Weinig 2012-02-19 12:57:08 PST
(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.
Comment 5 John Knottenbelt 2012-02-19 12:59:52 PST
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?
Comment 6 Sam Weinig 2012-02-19 13:20:23 PST
(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.
Comment 7 John Knottenbelt 2012-02-19 14:25:08 PST
Created attachment 127742 [details]
Patch
Comment 8 WebKit Review Bot 2012-02-20 19:48:46 PST
Comment on attachment 127742 [details]
Patch

Clearing flags on attachment: 127742

Committed r108293: <http://trac.webkit.org/changeset/108293>
Comment 9 WebKit Review Bot 2012-02-20 19:48:51 PST
All reviewed patches have been landed.  Closing bug.