weird... you shouldnt even be able to go above 360 in hue

yeah... it might be an openfl-only thing, tho im not sure

because i can see how just adding an event listener to the stage and measuring the distance from the mouse to the color causes this bug

you can go behinf the color bar, you can go beyond it...

its even weirder on the website

you shouldnt be able to though, and you also shouldnt be able to in the saturation / value graph... it should just clamp

i get different behaviour

arguably still wrong, but it does clamp

(ignore the gif encoding - though i kinda love it)

oh, weird if i move the sat / val to 0 (ie, black, then i get the same behaviour)... hsv is a pain

well, ill check it out at some point... will have to wait for a while though since im sick of looking at those hsv / rgb conversions 😄

understood 😅

the CV stuff melted my brain im trying to stay away from it

all oh the hough transform and canny edge detection aaaaaaaaaaaaaaaaaaaa

im moticing sometimes tooltips appear behind the object theyre supposed to be above

is there a reason why they arent just added to the top of the display list?

they defo should be top most

(minimal repro?)

its kinda random, and doesnt seem to be popping up for anyone else, so might bw a me-problem

I'm still trying to find a small reproducible setup where my syncValidation issue occurs in a reliable fashion, so no success. however I came accross a scenario where I get a

There was a problem validating this component as it has already been destroyed

crash, which coincidentally happens in the same

syncComponentValidation

function. my sample code is probably not really realistic, because it involves simulating very fast mouse clicks (although from within the same application and main thread).

knowing nothing about the component validation process my naïve question is why validate something that is already marked as disposed? cause

validateComponent

exits out on

_isDisposed == true

so nothing is ever done with it and the loop in

syncComponentValidation

always runs into count >= 10 for these cases.

So ill have to check, but iirc the reason is that you can dispose of something, and then a frame later (which is when invalidations run) it can try and do "something".... i think thats the reason anyway. Though you could argue that if the if the component is destroyed its (in)validation queue is purged, ill have to check on that. That said, the fact that you are seeing the warning indicates you are doing something wrong, my guess is you are trying to click a button in a dialog (or something) that has been destroyed - if that is the case, your framework should probably verify that dialogs arent there etc.

that error happened without my framework. I am sending very fast mouse clicks, only a few ms apart, using a

Timer.delay

based loop. it's probably cheating since a user won't be able to click that fast, although I have seen it happen with "larger" pauses between clicks. it just takes longer to occur, when clicks are further apart. my test project consists of a single button that will open a dialog. so click 1 will go to the button which will open a dialog, click 2 goes to modal background cover which auto-cancels the dialog, click 3 back on button and so on. so for very fast clicks

show

of dialog might not have completed / run when click on modal background cancels (and disposes) it.

looking at the code of

syncComponentValidation

there is no way (at least I see none) a disposed component will not end up running into

count >= 10

and produce that error message

do you have repro for the "has already been destroyed" warning? (rather than me having to guess and recreate)

I can upload a zip file so you can try for yourself

> a disposed component will not end up running into count >= 10 and produce that error message so looking at the code, it looks like it will throw an exception... after it tries 10 times... arguably that could be moved out of the "if > 10" (if the component is disposed) but the effect is basically the same anyway

cool - would be helpful

there you go... tested on Linux, probably also happens on Windows

I almost stumped myself, because the sample wasn't crashing, but then I realised I put a fix ala

if (this._isDisposed) return

at the start of my

syncComponentValidation