`set_buffer` is slow

[LoganDark]

On Windows 10, set_buffer can take upwards of 15-20 ms, which is noticeably slow.

Perhaps a no-copy API could be introduced to mitigate this.

[ids1024]

20 ms is pretty bad, since that gives you less that 60fps just calling set_buffer, before accounting for time spent actually rendering.

With some quick testing, I don't seem to see worse than around 1.5ms. Presumably a 4k buffer would take longer, though not by this much. Not sure how much difference CPU/memory/GPU speed/etc would have here.

If anyone is currently seeing performance like this with softbuffer on Windows or any other backend, I'd like to know exactly in what circumstances it's reproducible.

[hecrj]

@ids1024 I am getting 50ms on average to present a 4k window on macOS with the advanced-text branch of iced. I'm using an Intel i9 MacBook from 2019.

I can also reproduce the issue with just the animation example.

[ids1024]

#65 should improve performance on some platforms, though on macOS that's currently limited to the same approach.

#83 mentions a possible approach on macOS. I'd be happy to hear if anyone familiar with ABIs like this on macOS/iOS thinks this is a viable/ideal solution.

[LoganDark]

Now that I've had the opportunity to test softbuffer 0.3.0 with managed buffers, I can confirm that drawing a new frame into a 4K buffer can now be done in under 6ms on win32 (10ms in debug mode). I consider this issue solved on Windows :)

[LoganDark]

I left this open because my impression was that presenting is still slow on macOS (arguably more common since basically every Mac has a HiDPI display)

[notgull]

Oh, my bad

[madsmtm]

Let's track the macOS parts in #83.