Open brettfeltmate opened 3 years ago
a-hurst
commented
3 years ago Damn, the first two official klibs GitHub issues ever that weren't opened by Jon or myself, and they're on the same day! I'm just about to stop work for the evening, but I'll think about this and give you a response tomorrow! In the meantime, can you give a rough description of the paradigm in which this would be used? Just want to make sure I fully get the context.
brettfeltmate
commented
3 years ago I noticed that too! Big day for you.
It’s for the tracking task for Thales: user attempts to keep a cursor at centre screen (indicated by a fixation annulus) while it’s being buffeted by some ‘wind’ force.
I wanted to make the task more visually appealing. One idea was to have a series of concentric circles emanating from screen centre, but I didn’t want them to overlap the horizontal ‘track’ the cursor moves along.
So in terms of layers, imagine:
circles -> cursor track -> fixation -> cursor
Where each item overlays the preceding item(s)
This is purely ‘sugar’, so there’s absolutely no rush here. I know how to do this with the tools available to me, but it seemed like it could be useful for others in the future.
On Apr 30, 2021, at 8:41 PM, Austin Hurst @.***> wrote:
Damn, the first two official klibs GitHub issues ever that weren't opened by Jon or myself, and they're on the same day! I'm just about to stop work for the evening, but I'll think about this and give you a response tomorrow! In the meantime, can you give a rough description of the paradigm in which this would be used? Just want to make sure I fully get the context.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Not sure if this is better suited as a Drawbject property, or a blit() flag. In any case...
It would be handy if devs could specify a z-index which governed which stimuli gets 'visual priority' when two or more overlap.
ex: Two drawbjects [dA, dB] with respective z-indexes of 1 & 2 dA is stationary, dB is free to move. When dB intersects with dA, dB should not obfuscate dA but instead glide 'underneath'
Personally, I think making it a property of the Drawbject itself is more in line with KLibs' modus operandi. But I can imagine scenarios where developers might want to conditionally shadow this property only during a some event which is where a blit flag would come in handy.
I think (should test) that the only way to do this now is through rigid control of blit order. I'm pretty sure subsequent blits() will overlap previous ones. Making z-index a property of the drawbject itself would prevent a lot of headache for developers working on projects utilizing dynamic stimuli.
While this is doable (I think) using KLNumpySurface, that would be a lot of mental overhead on the developer's end to figure out.