Acknowledged
2 months ago

Provide polyfill where needed in Toybox.Graphics.Dc API

Basically, there should be no "[view]" sections below any of Dc methods in the docs.

The context is as follows:

I really don't understand the thought process behind adding a DC method that is supported on just some devices.

What does Garmin expect to happen when someone arrives at a need to use, say, setFill(bitmap) and it's not supported on some (seemingly random) models?

It's not like my need to tile an area with a bitmap will suddenly go away because setFill is not available on VA5. Nor will I want to dumb down the design for some models. Some people might consider that OK, but imnsho that's an amateurish hackery.

The only thing that will happen, realistically, is that I will be re-implementing setFill() for devices that don't have it, i.e. I will be making a homebrew polyfill.

To put differently, these new and shiny API methods are effectively useless, unless someone just happens to be targeting specific models supported by them.

It's never the " Let's look what supports setFill and that will be our target model list ! "

It's always the " We want to do X, let's see if the API supports it for the devices we target ".

eau_de_vie
Parents
  • 2 months ago

    The supported devices list is not arbitrary—in order for a device to support setFill(), it must have required hardware (in this case, a GPU), which only certain devices have. To be fair to you, this is not well-documented. The best surrogate for this is in the device configs you download with SDK Manager. In the compiler.json file for each device, specifically, if enhancedGraphicsSupport is true, the device will support setFill().

    We do our best to support things to the extent that is possible, and some devices have more capabilities than others. In cases like this, it's best to use has checks if you don't know whether your targets will support the feature:

    if(dc has :setFill) {
    // implement your setFill-enabled code here
}

Comment
  • 2 months ago

    The supported devices list is not arbitrary—in order for a device to support setFill(), it must have required hardware (in this case, a GPU), which only certain devices have. To be fair to you, this is not well-documented. The best surrogate for this is in the device configs you download with SDK Manager. In the compiler.json file for each device, specifically, if enhancedGraphicsSupport is true, the device will support setFill().

    We do our best to support things to the extent that is possible, and some devices have more capabilities than others. In cases like this, it's best to use has checks if you don't know whether your targets will support the feature:

    if(dc has :setFill) {
    // implement your setFill-enabled code here
}

Children
  • 2 months ago in reply to Brandon.ConnectIQ

    > The best surrogate for this is in the device configs you download with SDK Manager. In the compiler.json file for each device, specifically, if enhancedGraphicsSupport is true, the device will support setFill().

    Well noted, thanks.

    > if you don't know whether your targets will support the feature

    That was my main gripe - that `if` statement in your 3-liner requires an `else` block.

    There are two options what can go in that block - a custom implementation of setFill or an alternative, dumbed-down design of what's being drawn.

    The latter is typically not an option, not if a product aims at consistency across all supported devices, which is typically the case. Meaning that devs, who target wider range of devices and need setFill-like functionality for their design will need to re-implement setFill or they won't use it at all.

    Hence the request, for setFill & Co. to be actually useful, they need to have polyfill versions on inferior devices.

    The fact that's API methods' availability is subject to the SDK version and, independently, to a device model is really quite messy and inconvenient to work with.