Dynamically change uniformly applied color of a large set of area series?

[MediumSolid]

Here's the thing, I have a large set of area series stored in a dictionary whose color I need to dynamically change and it needs to be as fast as possible. Changing them iteratively in a for loop using configure_item and changing their fill color but is not practical at all since it's extremely slow and thus quite unpleasant to watch. I have also tried achieving the same thing relying on theme binding but that doesn't work at all. Color change and theme update is driven via color picker callback function.
I'm quite new to dearpygui and I've rummaged a bit through documentation but obviously that's not enough to fully grasp all the pitfalls and limitations of this library.

Area Series Construction:

for data in uv_data:
    x_data, y_data = data[0]
    color = data[1]
    fill_color = (int(max(color[0]*255, 1)), int(max(color[1]*255, 1)), int(max(color[2]*255, 1)), 255)
    area = dpg.add_area_series(x_data, y_data, parent=self.polygon_y_axis_tag)
   #area = dpg.add_area_series(x_data, y_data, parent=self.polygon_y_axis_tag, fill=fill_color)
    dpg.bind_item_theme(area, self.uniform_color_theme)
    self.series['areas'].append(area)

Initial Theme Construction Method:

with dpg.theme() as self.uniform_color_theme:
    with dpg.theme_component(dpg.mvAreaSeries):
        dpg.add_theme_style(dpg.mvPlotStyleVar_LineWeight, 0.0, category=dpg.mvThemeCat_Plots)
        dpg.add_theme_color(dpg.mvPlotCol_Fill, self.default_color)

Color Picker Construction (EDITED thanks to v-ein):

  dpg.add_color_picker(
      tag="color_picker_wheel",
      display_type=dpg.mvColorPicker_wheel,
      width=150,
      height=150,
      callback=self.color_picker_callback,
      default_value=self.default_color
  )

Update color callback:

def color_picker_callback(self, sender, app_data):
    self.default_color = app_data
    dpg.configure_item("color_block", fill=self.default_color, color=self.default_color)

    if not self.display_states["display_group_colors"]:
        parent_theme = self.uniform_color_theme

        with dpg.theme_component(dpg.mvAreaSeries, parent=parent_theme):
            dpg.add_theme_style(dpg.mvPlotStyleVar_LineWeight, 0.0, category=dpg.mvThemeCat_Plots)
            dpg.add_theme_color(dpg.mvPlotCol_Fill, app_data, category=dpg.mvThemeCat_Plots)
        
        dpg.bind_item_theme(self.polygon_y_axis_tag, parent_theme)
        self.update_plot()
        print("Changing Default Color")

For additional context what I'm trying to build is a UV viewer with limited functionality.

[v-ein]

Looks like you attached the same code snippet under both "Color Picker Construction" and "Update color callback" 😂.

Anyway... I bet that when you try to use themes, the area series remain transparent no matter what color you specify in the theme - correct? If so, here are some bad news for you: area series uses the fill color specified in add_area_series (defaults to transparent) and does not use the fill color from the theme at all. That is, the only way to recolor them is to do configure_item on each one. You can wrap that in with dpg.mutex(): to prevent rendering with half the image recolored and half in the old color:

with dpg.mutex():
    for area in self.series['areas']:
        dpg.configure_item(area, fill=...)

How many areas do you have in your plot? Judging by the picture, it must be a lot - thousands maybe? Another piece of bad news is that functions like configure_item get pretty slow if there are thousands of widgets in the GUI. We're going to eventually optimize this, but for now the above loop might be pretty slow, so you might notice "hiccups" in the GUI if the loop is called multiple times (not sure how often the callback is called in your app).

Unfortunately I don't know of any widget that would take colors from the theme (or from any other single source) and would render multiple arbitrary polygons. Looks like a loop is the only way to recolor them, be it area_series or any of the drawing primitives.

---

Also, a couple of things I've noticed in your code.

In color_picker_callback, you're adding components to the theme without deleting the previously created components, which means the theme will grow with time, having a series of components where each subsequent color overrides the previous setting -- you can check that with dpg.show_item_registry(). This shouldn't affect the display but will degrade rendering performance as more components are added.

FWIW you can actually do a set_value on a color (i.e. the item created with add_theme_color) to change it. Like this:

self.fill_color_item = dpg.add_theme_color(dpg.mvPlotCol_Fill, app_data, category=dpg.mvThemeCat_Plots)
# ...
dpg.set_value(self.fill_color_item, new_color)

Of course it won't help with the fill color on area_series, I just mentioned this in case you want to configure colors on other widgets.

Also, it turns out plot axes ignore themes bound to them, so if you want to apply a theme to all series (e.g. to set line thickness), bind it once to the plot itself rather than to the Y axis. There's no need to bind the theme individually to every area series for that.

If you still struggle with performance issues, take a look at DearCyGui.

[MediumSolid]

Hey man, thanks for the fast reply.

Looks like you attached the same code snippet under both "Color Picker Construction" and "Update color callback" 😂.

Yeah, that's my bad, I know it's not an excuse but it was really late when I was writing this, it's fixed now, though.

Anyway... I bet that when you try to use themes, the area series remain transparent no matter what color you specify in the theme - correct? If so, here are some bad news for you: area series uses the fill color specified in add_area_series (defaults to transparent) and does not use the fill color from the theme at all. That is, the only way to recolor them is to do configure_item on each one. You can wrap that in with dpg.mutex(): to prevent rendering with half the image recolored and half in the old color:

That's not surprising to me at all, because at first I did everything the correct way as you've described it. (hence the image in bottom of the post as proof). I only hoped that an alternative way of batch coloring of all series existed, which turned out to not be the case as you correctly stated. And ohhh yeah, there's 15597 area series which is astronomically a lot, and I can only assume area series and plots were never created for such unoptimized usage of high volume of individual data, not to mention the fact that (as you can probably imagine) this is only scratching the surface when it comes how much data the intended software should support (this is all part of a larger blender addon that's dealing with non-destructive baking setup).

In color_picker_callback, you're adding components to the theme without deleting the previously created components, which means the theme will grow with time, having a series of components where each subsequent color overrides the previous setting -- you can check that with dpg.show_item_registry(). This shouldn't affect the display but will degrade rendering performance as more components are added.

Huh, believe it or not this did cross my mind, since the idea of adding new themes when updating certain attributes of the theme came from pygui-demo's Shade Series, where I've strangely noticed the same lack of cleanup after creating a theme over and over again via _cb_alpha method. But I could have just simply missed the cleanup process, wouldn't be the first time to not notice something obvious, to be honest.

If you still struggle with performance issues, take a look at DearCyGui.
Thank you for the recommendation but I'm I think I'm gonna stick to to DearPyGUI for now when it comes to pure UI for actual UV geometry representation I'm going to have to resort to gpu module in python.

Again, thank you for taking the time to demystify DearPyGUI to me and to point out its limitations. Have a nice day.

[MediumSolid]

I know it's frowned upon when writing additional comments on already solved topics, but I've stumbled onto some hurdles when imploying gpu module in resolving my task at hand so I would like to give some correct pointers to whoever is reading this in the future. So here it goes.

As of right now, Blender's gpu module doesn't not allow for multithreading, since it's context for drawing management can only exist on the main thread, therefore I suggest switching to any other third party libraries or wrappers such as ModernGL that does allow for that. I have personally switched to using ModernGL, and in addition to it being multi-thread friendly it's also (to no one's surprise) light years faster than solely relying on DearpyGUI for mesh drawing, plus it's much more modular in that regard.