refreshing problem (guru level)

[tester]

From what I see, if there are 2 visual modules (each with it's own mgui), one on top of the other, then if you wish to redraw one of these modules, the second one also is forced to redraw. Unfortunately this means some unplreasant consequences.

Scenario.

Top layer is refresed at 25 or 50Hz rate. Cursor playback and some interactions. Nothing very special.

Bottom layer is an envelope graph (c.a.600x400 pixesls, scaled to higher via FS zoom routines), upper and lower part vectorized from 8k points (i.e. 2 arrays per 8192 points) or less (dynamically, from other source). Envelope graph itself is not really refreshed, only once per a while.

But because of the top layer - the bottom layer is being refreshed at the same rate as the top layer, and this produces huge CPU consumption (fortunately not on the core where blue streams go, green data go through other cores via Windows routines). Graph is created by standard FS green prims.

To solve this, I tried 2 methods.

1) Resample prims. If I resampled data to (2x) 300 points - CPU consuption was not that bad. But graph, and it's relation to content - was practically unusable.

2) Bitmap replacement (get bitmap from graph once, and show it instead of vectorized graph). This could work, but... well, in scale 1:1 it looks fine, but in other scales (app resized) - looks very blurry, unusable.

3) Third method that should work is to move interaction layer below the graph, but then the visuals will be somewhat out of content.

So my question is. Is there a way to solve this? For example, to force bottom layer to be refreshed only once? Or different way (via ruby?) of getting/drawing such bitmap? Or handlig graph data via ruby?

When closing visual with such graph, CPU goes almost to zero.

I'm not posting any schematic here, because this is a general problem. Perhaps someone solved this?

[Youlean]

Create bitmap from envelope and then recreate bitmap when you resize the app. That would be a solution.

[tester]

This is what the Redraw node can do on Bitmap prim? When zoom options (via ExeZoom prim) are used, it creates new size of the bitmap?

Context.

I'm doing the project in some scale, and use zoomed workflow. On export, app is zoomed according to workflow. From what I see on zoomed workflow - bitmap is a bit blurry, compared to vectors.

Thus - the workflow zoom is independent from ExeZoom prim activity?

[Youlean]

Sorry, I am not familiar with exezoom