You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I remember seeing a bit of discussion about this somewhere, but can't find it by searching.
What's the rationale for the image data settings being accessible via a getter function (getImageDataSettings) instead of via a read-only attribute or just as individual attributes on ImageData directly?
While getImageDataSettings does match the canvas contexts' getContextAttributes API, I would argue that an ImageData object is sufficiently different from a canvas context that it may be better for the APIs to differ:
A canvas context has state, and is long-lived (you create it then reuse it). You're therefore more likely to just store the context attributes, or at least the ones relevant to you, in the same place that you store the canvas context, instead of repeatedly calling getContextAttributes. ImageData objects are less stateful--while you can mutate their data, the API is designed around being able to create them easily and often.
A canvas context has many writable properties which affect rendering state, so it makes sense to place the non-writable ones behind a getter function to avoid confusion. All ImageData properties are readonly, so there's no such confusion.
Adding on to the above point, ImageData's existing properties (width and height) are in the same category as the one(s) being added here in that they are purely "descriptive", so it doesn't make sense to arbitrarily split further properties into a dictionary behind a getter function.
Feature detection is less futureproof if the new properties are behind a getter function. If, for instance, colorSpace was a property on ImageData, then you could query support for it with ImageData.prototype.hasOwnProperty('colorSpace'). While you can query support for the existing proposal with ImageData.prototype.hasOwnProperty('getImageDataSettings'), this doesn't actually tell you which settings are supported. If more settings are added in the future (e.g. premultiplication), then you'll have to call ImageData.prototype.hasOwnProperty('getImageDataSettings') to check if the settings dictionary is supported in the first place, construct an ImageData object and call getImageDataSettings on it if so, then call hasOwnProperty on the settings dictionary to see which specific settings are supported.
The text was updated successfully, but these errors were encountered:
I remember seeing a bit of discussion about this somewhere, but can't find it by searching.
What's the rationale for the image data settings being accessible via a getter function (
getImageDataSettings
) instead of via a read-only attribute or just as individual attributes onImageData
directly?While
getImageDataSettings
does match the canvas contexts'getContextAttributes
API, I would argue that anImageData
object is sufficiently different from a canvas context that it may be better for the APIs to differ:getContextAttributes
.ImageData
objects are less stateful--while you can mutate their data, the API is designed around being able to create them easily and often.ImageData
properties are readonly, so there's no such confusion.ImageData
's existing properties (width and height) are in the same category as the one(s) being added here in that they are purely "descriptive", so it doesn't make sense to arbitrarily split further properties into a dictionary behind a getter function.colorSpace
was a property onImageData
, then you could query support for it withImageData.prototype.hasOwnProperty('colorSpace')
. While you can query support for the existing proposal withImageData.prototype.hasOwnProperty('getImageDataSettings')
, this doesn't actually tell you which settings are supported. If more settings are added in the future (e.g. premultiplication), then you'll have to callImageData.prototype.hasOwnProperty('getImageDataSettings')
to check if the settings dictionary is supported in the first place, construct anImageData
object and callgetImageDataSettings
on it if so, then callhasOwnProperty
on the settings dictionary to see which specific settings are supported.The text was updated successfully, but these errors were encountered: