Performance issue

[PyHubs]

The UI framework is INCREDIBLY leggy/slow. Please fix this issue because it looks very good and I will like to use it in my future projects. I noticed the images are the main thing that are slow.

[rdbende]

Unfortunately, I can’t deal with that right now, but I'll look at it as soon as I have time.
The problem here is that almost all images are 20x20 pixels and tk has to repeat these to draw a widget. For some widgets, scaling to a larger size is not possible, but for a LabelFrame, Notebook, or Treeview border it can definitely be useful.

[RedFantom]

In my experience, pixmap themes in ttk can be slow with a large number of widgets if the pixmaps contain an alpha channel, which the PNG images of this theme do. The only reliable way to speed it up is to convert the images to a format like GIF, where pixels can be absolutely transparent but not partially. To do this nicely, it is required to blend the partially-transparent pixels with the background colour of choice and then convert to a GIF file.

Sometimes a bug may exist in a theme that makes it slow and a small adjustment can help. plastik was very slow due to an issue in one of the Notebook pixmap specifications. However, such a level of slowness you really can't get around, and from the example for this theme, I'm pretty sure no such issues exist here.

I think this has little to do with the theme itself, and mostly with Tk/ttk. Tk/ttk was just not built in a time when transparency was available in most image formats, let alone used a lot in UIs. Making themes without true alpha channels is merely a work-around for an issue that will probably never go away. But it's a good, reliable work-around nonetheless.

[rdbende]

I think the complete elimination of the alpha channel as a good idea, but there is something else here. I’ve noticed that inside a LabelFrame or Notebook, Tk/ttk renders the state change of widgets much more slowly than outside them. This is definitely due to the small image size of the borders.

[rdbende]

In v1.4 I tried to remove all the transparency, unfortunately, it still remains, but on Ubuntu, it works perfectly well, but I'm not happy with the performance of Windows, although it might be possible with gifs, unfortunately, I'm not friended with them, so this won't happen for a time.
Anyway, be sure to check out the release with new widget styles!

[PyHubs]

Alright rbende. But i dont now really need to work on GUIS but for the next project ill need GUIS will see :)

[RedFantom]

@rdbende A little while ago I actually made a GIF-version of the theme in my fork. Feel free to check it out, though it's not for azure dark. I did it with an automated script, some touch-ups might be needed.

[rdbende]

Thanks for the tip, I wrote my own Pillow converter, so that's no problem now. I know it would have been faster with some ImageMagick and shell stuff, but I prefer Python and Pillow.
However I noticed that the png images aren't perfect either, somehow an extra pixel slipped in, so I'll fix it sometime. 🤔️

[bosd]

@RedFantom Does your fork solve(/improve) the performance issue?

[bosd]

How about SVG images?? What is the reason the Sunvalley SVG version exsists?

[rdbende]

The SVG-based theme was just an experiment with the Tksvg package, and in theory it should improve the appearance on high DPI displays, tho I couldn't try it out.
I think it makes the performance even worse.

[RedFantom]

@bosd The fact that Tkinter is slow when using PNG-pixmap themes is well-documented, and this may be alleviated by using GIF-pixmap themes.

If you need higher performance than a GIF-pixmap theme can provide, you have to look outside of pixmap themes altogether.

I'd like to point out that @rdbende has made a GIF version also, and it's probably better than my quick-and-dirty conversion.

SVG probably makes it worse, especially on first load, because the images have to be rendered to pixmaps before they can be used by Tkinter. The high DPI images will be bigger, and hence the transformations that are applied to build UI elements from them will probably be a bit slower indeed. I think on low DPI screens it should not make (much of) a difference.