Static Maps Api + Colors sourced from time-based logic = mutliple api requests per second and crashes in editor

Howdy Kustom team!

As a preface, although the issue I will be describing has resulted in excess of $100 in outstanding charges from GCP, I am not seeking reimbursement or financial reconciliation from the Kustom team; I just want to iron out this bug to prevent this from happenning again.

I will be including kode snippets and my exported wallpaper file stripped of my google static maps api key in order to assist in troubleshooting, and I'm running this on a Samsung Galaxy a50 (SM-A505U1) with android 11 4.14.113; if there is any other information I can provide, please do not hesitate to reach out to my email ([email protected])

With that out of the way, on to the actual issues!

I've implemented some ~fun~ logic that sources colors from the time that essentially generates an rgb global color used to mimic the natural gradiation of hue throughout the day in order to have a more natural integration of my physical and digital surroundings. The way that it works is it takes the current time in seconds from midnight <gv(ctime)> and normallizes this in three different ways to produce natural curves of the red green and blue channels mimicking the refraction of sunlight through the atmosphere throughout the day. It outputs this color via a global <gv(circRthm)> which is then referenced by and mixed into the other 6 global colors, <gv(bg)> <gv(bg2)> <gv(bdy)> <gv(stx)> <gv(hlt)> <gv(fg)>, in various ways. An additonal global (which often simply does not work in arithmetic computations and needs to be manually copied to the other formulas (bug #1)) of <gv(dim)> is used to factor my current backlight value (which the phone automatically gradiates based on the light it senses) into the general color balance of the entire ui, resulting in natural day/night and everything inbetween modes. All of this combined generates a cohesive pallete that seamlessly transitions, second-by-second from a red based palette at midnight, through the rainbow, to a purple based palette by the end of the day, and automatically gradiates between light and dark modes as I physically traverse my surroundings. Overkill— I know.

The main issue I'm running into seems to be stemming from this time based logic updating every single second, as the editor preview cannot keep up with the amount of changes taking place and grinds to an absolute halt if I open it as usual. To get around this, I've exported an empty preset which I have to first load into, I then re-enable and re-disable all of the preview-related settings, load from onscreen preset, and then reload the current workspace. This is the only way I've found to get the editor preview to stop trying to immediately render everything on initial load. If I do not do this, all of the time based logic still attempts to render on load despite the cached preview settings (bug #2).

On to the fun stuff, and the meat of the matter; I have implemented usage of the static maps api to render a local map on one of my homescreens, and it utilizes these time-logic-based colors as part of it's url requests which are in turn fed into an image container as it's source url. I pass all of the style editing syntax in a single url, from which google returns an image of my current location, styled to fit the same cohesive environment as the rest of the ui, and subsequently- my surroundings. As of last night, I was billed for over $100 from gcp (which I use exclusively for this single map), so I looked into it and turns out– there's been nearly 100,000 requests in the last 4 days :/

What I think is going on is every time the colors change (which is atleast once a second) it's issuing a new request to the static maps api, resulting in the editor using all of it's resources to change the colors, download the new map, and repeat the process (bug #3), so any time I open the editor, it starts belligerently requesting the map.

Please advise.

gv(circRthm)- used to source rgb from time of day:

$ce( cm(184,(86400+gv(ctime))/86400*255,(43200-mu(abs,43200+gv(ctime)))/43200*255,if(df(hh)<=6,(mu(abs,10800+gv(ctime)))/86400*255,if(df(hh)>=18,(21600+mu(
abs,43200+gv(ctime)))/86400*255,mu(abs,21600-mu(abs,43200+gv(ctime)))/43200*255))),lum,gv(dim))$

gv(dim)- used to adjust for light conditions:

$mu(round,(255-si(system, screen_brightness))/255*100,0)$

gv(ctime)- used to get current time in seconds:

$(tf(0h0m0sa0d, ss) + ( tf(0h0m0sa0d, mm) * 60 ) + ( tf(0h0m0sa0d, hh) * 60 * 60 ))$

gv(wave1)- used to normalize time into parabolic shape

$mu(round,(43200-mu(abs,43200+gv(ctime)))/432)$

gv(bg2)- used as secondary background color, provided as an example of how all of these work together (note that gv(dim) cannot be substituted here, despite being indentical in syntax):

$ce(ce(ce(ce(gv(bg),gv(circrthm),gv(wave1)/9), sat,mu(abs,127-si(system, screen_brightness))/255*100), lum, si(system, screen_brightness)/255*100), alpha, 0+mu(round,(255-si(system, screen_brightness))/255*2/3*100,0))$

Static maps request url:

https://maps.googleapis.com/maps/api/staticmap?center=$li(lat)-(li(lat)%0.001)$,$li(lon)-(li(lon)%0.001)$&zoom=$gv(mapzoom)$&size=4098x4098&scale=4&style=feature:all|element:labels|visibility:on&style=feature:landscape|element:all|visibility:off&style=feature:road.highway|element:all|visibility:simplified|color:0x$tc(low, tc(cut, gv(stx), -6))$&style=feature:road.arterial|element:geometry|visibility:simplified|color:0x$tc(low,tc(cut, gv(bdy), -6))$&style=feature:road.local|element:all|color:0x$tc(low,tc(cut, gv(stx), -6))$&style=feature:road.local|element:all|color:0x$tc(low,tc(cut, gv(bg), -6))$&style=feature:water|element:all|color:0x$tc(low,tc(cut, gv(fg), -6))$|visibility:on&style=feature:transit|element:all|visibility:simplified|color:0x$tc(low,tc(cut, gv(hlt), -6))$&key=

Why don’t you use a flow to update the global variables on a cron, say every 15 mins.

That is one hell of an expensive widget :frowning: doesn’t gcp have any kind of limit for api use rather than pay as you go plan.