Notable latency when dragging sliders

[Eemilp]

I'm experiencing notable latency when dragging sliders in vkdt 0.8.99-67-g6a75ba87 as well as previous versions. See this video. This is with 16mpix image and level of detail setting at 1, with a AMD Ryzen 5 PRO 4650U and its iGPU.

I'm aware that this is a bit the case of "can i speed up rendering on my 2012 on-board GPU?", but darktable and rawtherapee manage to feel much smoother despite the processing being significantly slower.

[hanatos]

AMD Ryzen 5 PRO 4650U and its iGPU. ouch.

LOD<=1 is the highest possible, i.e. it will always render full res. did you try to set to at least 2?

also you're probably aware that these sliders are nuklear properties, i.e. the mouse doesn't directly correspond to the grey bar but has extended precision by using the whole screen as range.

i don't really feel like optimising for devices below a certain level (other than the already existing LOD switch). especially i don't want to implement a complicated monster as for darktable again (cropped and downsized pixel pipelines running at the same time and asynchronously, sync nightmares included). seems it's not very hard to jump over a threshold of hardware capability to make this unnecessary (bringing only bloat, code complexity, and in fact slowdown).

[Eemilp]

LOD<=1 is the highest possible, i.e. it will always render full res. did you try to set to at least 2?

Yes, at 2 it's quite usable already, but I do like zooming into my images.

also you're probably aware that these sliders are nuklear properties, i.e. the mouse doesn't directly correspond to the grey bar but has extended precision by using the whole screen as range.

Somehow I managed to miss this, thanks!

i don't really feel like optimising for devices below a certain level (other than the already existing LOD switch). especially i don't want to implement a complicated monster as for darktable again (cropped and downsized pixel pipelines running at the same time and asynchronously, sync nightmares included). seems it's not very hard to jump over a threshold of hardware capability to make this unnecessary (bringing only bloat, code complexity, and in fact slowdown).

Makes sense. I guess it would be nice for the pixel pipeline to not block the gui, but that is added complexity of course. This GPU is just too weak for processing in real time despite plenty of vram.

At least I now have another excuse to get a new PC :)

[hanatos]

i think i may change my mind wrt older or weaker devices. new gpus have ridiculous prices. might look into async processing, could be not too much trouble.

On Mon, Jul 29, 2024, 11:09 Eemil P @.***> wrote:

LOD<=1 is the highest possible, i.e. it will always render full res. did you try to set to at least 2?

Yes, at 2 it's quite usable already, but I do like zooming into my images.

also you're probably aware that these sliders are nuklear properties, i.e. the mouse doesn't directly correspond to the grey bar but has extended precision by using the whole screen as range.

Somehow I managed to miss this, thanks!

i don't really feel like optimising for devices below a certain level (other than the already existing LOD switch). especially i don't want to implement a complicated monster as for darktable again (cropped and downsized pixel pipelines running at the same time and asynchronously, sync nightmares included). seems it's not very hard to jump over a threshold of hardware capability to make this unnecessary (bringing only bloat, code complexity, and in fact slowdown).

Makes sense. I guess it would be nice for the pixel pipeline to not block the gui, but that is added complexity of course. This GPU is just too weak for processing in real time despite plenty of vram.

At least I now have another excuse to get a new PC :)

— Reply to this email directly, view it on GitHub https://github.com/hanatos/vkdt/issues/133#issuecomment-2255402619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMAKKPXMNETUDTX3ZLXZY3ZOYBFZAVCNFSM6AAAAABLKMEHUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJVGQYDENRRHE . You are receiving this because you commented.Message ID: @.***>

[hanatos]

pushed some async compute in the background, redrawing ui at different frequency. let me know if that works for you. maybe you want to also set the frame_limiter in ~/.config/vkdt/config.rc so it doesn't refresh at idiotically high frame rates.

[Eemilp]

Tested by building the latest master (463d255). It still stutters a bit, but a definite improvement! (Here is a clip). Adding a frame limiter helps indeed too, in my case 16 is a small improvement and around 50 seems to make the mouse feel smooth. Overall a big improvement for usability. Playing around a bit I also noticed that reducing the sensitivity of the sliders also made interaction easier despite the stuttering.

[hanatos]

okay.. this sounds like there is still some interference between the various "clock domains" involved here. i suppose it's time to reimplement the synchronisation with timeline semaphores here.

[hanatos]

the new git version comes with a reimplementation of all the synchronisation code via timeline semaphores. they are simply the better concept, this was actually fun to do. in my limited tests this seems to work well for still images, videos, stopped videos, and interactive rendering with grabbed mouse/keyboard (quake).

if you'd like to test again i'd be interested how it works on the lower end of hardware. for smooth ui rendering i'd certainly dial down the frame_limiter to 16ms (60Hz) or even 6ms (160Hz) depending on the refresh rate supported by the screen.

[Eemilp]

Unfortunately the performance seems about the same on my hardware (clip). Here the frame limiter is 16ms.