Toybox::Graphics::Dc::getPoint or getPixel or readPixel

Could you explain what you are trying to do? There might be other ways to handle it during compilation, etc.

Toybox::Graphics::Dc::getPoint or getPixel or readPixel

Hi,

I'm making an analog watchface using the Graphics Api (drawLine,FillPoly,FillCircle, ..) and I'd like to antialias those primitives once they are drawn.
I know there is already built-in antialiasing for fonts but not for primitives drawing... That's why...

Thanks,

Hi,

I'm making an analog watchface using the Graphics Api (drawLine,FillPoly,FillCircle, ..) and I'd like to antialias those primitives once they are drawn.
I know there is already built-in antialiasing for fonts but not for primitives drawing... That's why...

Thanks,

Any tips or advices ? Do you think this function could be added to the SDK ?

The closest thing we have that would fit some of what you're looking for is Graphics::Dc::drawPoint(). Since your goal is attaining the ability to anti-alias graphics, I'll speak to that briefly.

Anti-aliasing graphics on the device would impose a huge performance hit on anything drawn to the screen because our devices simply don't have the power to do anti-aliasing quickly. It's not completely off the table--we may add anti-aliasing of graphics sometime in the future--but if we did, it would be something we'd take time to do carefully to make sure we're doing things efficiently as possible. In the short term, however, this is not something we plan to add to the SDK.

I can submit your suggestion as a feature request and see what the team thinks. My feeling is that we'd probably prefer to implement some kind of anti-aliasing system rather than give access to the frame buffer.

Doing pixel operations on the display is not something we are going to be able to support at this time. The Virtual Machine is simply too slow to support this type of an interface. You may see some posts around here where other developers are trying to optimize the way they handle graphics calls to prevent sluggish behavior and excess battery drain on the device. These issues can arise when making a large number of graphics calls, which handle all the pixel operations for drawing shapes in the native graphics driver. This is a feature we can consider for higher powered systems in the future, but doing pixel operations through the VM on our wearables, is just not feasible.

Doing pixel operations on the display is not something we are going to be able to support at this time. The Virtual Machine is simply too slow to support this type of an interface. You may see some posts around here where other developers are trying to optimize the way they handle graphics calls to prevent sluggish behavior and excess battery drain on the device. These issues can arise when making a large number of graphics calls, which handle all the pixel operations for drawing shapes in the native graphics driver. This is a feature we can consider for higher powered systems in the future, but doing pixel operations through the VM on our wearables, is just not feasible.

Thanks for your answer.
We already do pixel operations since we have a drawPoint() function. So having a getPoint() is adding just adding its counterpart.

Talking about battery drain is a matter of users in the end : some will prefer preserving battery with less eyecandy graphics where others will prefer eyecandy graphics at the price of charging their watch more often...

So please, add the function and let decide the user and the developer of what they want to see on their watch !

Thanks,

So please, add the function and let decide the user and the developer of what they want to see on their watch !

How many pixels can you modify in a single call before you get a watchdog timeout? If you had 'getPixel' would you actually be able to do your proposed anti-aliasing without running into problems? I realize you could reduce the area to apply the technique to, or apply it to small blocks at a time, but I have serious doubts that it would actually be workable.

Lets assume for a second that you can successfully read/write pixel data. Many devices only support 16 colors, so you aren't going to get very good control over the output (e.g., if you draw an orange line, what color are you planning to twiddle the edges to).

I've never considered trying to implement anti-aliasing, and I'm not even sure how you'd achieve it with just a single frame buffer. Are you planning to implement some sort of full-screen anti-aliasing (blur), or are you wanting to just draw a primitive, then walk the entire screen looking for pixels of the color of that primitive, and then modifying the adjacent ones that should be modified?

Travis

How many pixels can you modify in a single call before you get a watchdog timeout? If you had 'getPixel' would you actually be able to do your proposed anti-aliasing without running into problems? I realize you could reduce the area to apply the technique to, or apply it to small blocks at a time, but I have serious doubts that it would actually be workable.

Lets assume for a second that you can successfully read/write pixel data. Many devices only support 16 colors, so you aren't going to get very good control over the output (e.g., if you draw an orange line, what color are you planning to twiddle the edges to).

I've never considered trying to implement anti-aliasing, and I'm not even sure how you'd achieve it with just a single frame buffer. Are you planning to implement some sort of full-screen anti-aliasing (blur), or are you wanting to just draw a primitive, then walk the entire screen looking for pixels of the color of that primitive, and then modifying the adjacent ones that should be modified?

Travis

About watchdog timeout, yes you're right, to antialias the full screen, it would take probably 2 or 3 passes to complete depending on the number of pixels you have to draw...

About 2nd question, I am already working for a device that has 16 colors (fenix 3), but please recall that the system fonts are antialiased and even if you don't have dark orange or dark blue, you can still use greys 0x555555 and 0XAAAAAA as the system does today. It's not perfect but it's better than nothing.

My idea is to rasterize everything and then go through the entire frame buffer but this may be to slow and I'll have to switch to the first solution : draw a primitive and antialias it... It relies alot on the speed of the getPixel() function...

And remember that when you want to use a custom font, there is no antialiasing mechanism so it could be interesting at least for custom fonts !

thanks,