# How much performance "cost" with GUI resizing?

**URL:** <https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318>\
**Category:** Uncategorized\
**Created:** [24 February 2021 18:07 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318 "2021-02-24T18:07:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nonlinear](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Nonlinear](https://iplug2.discourse.group/u/Nonlinear)\
**Post date:** [24 February 2021 18:07 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/1 "2021-02-24T18:07:23Z")

</div>

User-resizable plugin GUIs are all the rage these days - and a big focus of iPlug2 - but I wonder if there are “side effects” most users don’t consider.

I don’t know how iPlug2 GUI resizes bitmaps but I assume it uses some sort of resampling and/or interpolation algorithm(s). The CPU effort required for that may be insignificant for static images - like GUI backgrounds - but what about dynamic elements like meters, spectrum displays, etc., that need to be redrawn CONSTANTLY? What is the CPU “cost” for continuously resizing these multi-frame bitmaps as the plugin is running?

Most users these days want to run lots and LOTS of plugins where every CPU cycle counts. If having a resizable GUI cuts into that ability then they need to be informed. I tend to think fixed size choices from dedicated sets of bitmaps - rather than infinitely variable interpolated/resampled sizes - is a better option. Yes/no?

---

<div class="post-metadata">

**Author:** ![olilarkin](https://yyz2.discourse-cdn.com/free1/user_avatar/iplug2.discourse.group/olilarkin/32/2_2.png) [@olilarkin](https://iplug2.discourse.group/u/olilarkin)\
**Post date:** [24 February 2021 19:05 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/2 "2021-02-24T19:05:00Z")

</div>

iPlug2 uses GPU backends (except for SKIA-CPU) where displaying a texture with a different scale is not very expensive. Also bitmaps are not great for scalable UIs anyway.

---

<div class="post-metadata">

**Author:** ![Nonlinear](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Nonlinear](https://iplug2.discourse.group/u/Nonlinear)\
**Post date:** [26 February 2021 19:45 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/3 "2021-02-26T19:45:09Z")

</div>

Vector graphics may be easy to scale on the fly but if you want “photorealistic” GUIs you need to use bitmaps (raster graphics). No way I know of to make smooth shading, gradients, etc., with vector art.

What I would like to do is have 3 fixed sets of bitmaps, e.g., 1x 1.5x, 2x, and then provide a means to select the scale at runtime. I have something that works in iPlug1 but I am missing the step on how to force a complete redraw. Currently it requires closing the plugin window and re-opening to redraw at the new scale.

---

<div class="post-metadata">

**Author:** ![olilarkin](https://yyz2.discourse-cdn.com/free1/user_avatar/iplug2.discourse.group/olilarkin/32/2_2.png) [@olilarkin](https://iplug2.discourse.group/u/olilarkin)\
**Post date:** [26 February 2021 20:03 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/4 "2021-02-26T20:03:15Z")

</div>

you could probably do something with IControl::OnRescale() to choose a new bitmap. But this sounds like premature optimization

---

<div class="post-metadata">

**Author:** ![Nonlinear](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Nonlinear](https://iplug2.discourse.group/u/Nonlinear)\
**Post date:** [27 February 2021 17:59 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/5 "2021-02-27T17:59:07Z")

</div>

“Premature optimization”? Not sure what that means. If I can do something at build time that reduces CPU/GPU efforts at runtime then yes, that is optimizing AFAIK.

I know how to redraw individual controls, text, etc., but is there any command that forces a complete redraw of the _entire_ plugin - i.e., the same result as closing then immediately reopening the plugin window?

---

<div class="post-metadata">

**Author:** ![olilarkin](https://yyz2.discourse-cdn.com/free1/user_avatar/iplug2.discourse.group/olilarkin/32/2_2.png) [@olilarkin](https://iplug2.discourse.group/u/olilarkin)\
**Post date:** [27 February 2021 19:31 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/6 "2021-02-27T19:31:58Z")

</div>

just do the normal thing first, then if you find it is too slow, do something clever to optimize it

---

<div class="post-metadata">

**Author:** ![radiofarmer](https://avatars.discourse-cdn.com/v4/letter/r/f475e1/32.png) [@radiofarmer](https://iplug2.discourse.group/u/radiofarmer)\
**Post date:** [1 March 2021 12:24 UTC](https://iplug2.discourse.group/t/how-much-performance-cost-with-gui-resizing/318/7 "2021-03-01T12:24:22Z")

</div>

> [@Nonlinear](#):
>
> but is there any command that forces a complete redraw of the _entire_ plugin - i.e., the same result as closing then immediately reopening the plugin window?

`SetAllControlsDirty()` will cause all controls to be redrawn. I believe it calls `SetDirty(false)` for each control, with `false` specifying that the control’s ActionFunction should not be triggered (which is good here, since action functions themselves might cause redrawing to occur). This isn’t _exactly_ the same as destroying and recreating the UI, but it will cause `Draw` to be called for all controls, which would allow you to run your mipmap routine during that function.

I think Oli’s right that this optimization may not be necessary, especially with Skia. Before you try to optimize any graphics processing yourself, try using Skia instead of NanoVG. With NanoVG, the GUI was using 20% of the CPU, and after I switched the backend to Skia, that dropped to almost zero.
