General low performance of wish in Windows
lyon
Could someone tell me if there is a work around for that ?
Furthermore, is there any plan to improve that ?
This poor performance prevents for example the development of heavy
graphical themes for Ttk under Windows.
Any hint welcome.
Best regards,
Lyon
lyon
it to the one you get on linux on similar hardware.
Alexandre Ferrieux
> To be clearer: I am mentioning *graphical* performance and I compare
> it to the one you get on linux on similar hardware.
Interesting -- though frustrating :}
Do you have more details on the task on which you observed the
difference ?
If they can be packet into a reasonably sized script and the diff is
salient, please post a report on the SF tracker.
-Alex
Donal K. Fellows
> One can see a real difference in performance in wish under windows.
> Could someone tell me if there is a work around for that ?
The problem is (almost certainly) that Tk is using a drawing model
that is based on the X11 model, which is inefficient on Win. It would
be possible to a model that is closer to the Win model (and which,
curiously could be still pretty good on X) but that's a lot of work so
it's not happened.
I've no idea about workarounds, but you mention "graphically heavy
themes" which makes me think that you might also be just after a high-
performance renderer for photo images. If so, we'd *love* something
better than what we have now! We know the code there is poor, but lack
the specific knowledge to improve it. Contributions welcome. (It's
probably easier to develop it for 8.6 where the photo image datamodel
and rendering code has been separated; the maintainers - well, myself
probably - can handle backporting.)
> Furthermore, is there any plan to improve that ?
There was a plan ages ago (TkGS, http://wiki.tcl.tk/2177 indicates
that it's been mostly dead since 2002; that page has only had
maintenance since then, not new content) but it never fully "got to
first base". I've no idea why it didn't make the step up.
Donal.
lyon
Well, it is a bit difficult to post as a whole but for you to get the
picture
(if I may say so...). We have developped a theme with Tile. This theme
uses
a lots of small icons and graphical elements than are almost all as
small as borders
or lines.
The overall result under linux is nice and pretty fast.
But under Windows, we have to wait for something like 20-30s for the
initial
drawing of the main window and each time we switch from a panel inside
the
notebook that almost fully covers the top window.
Afterwards, the application response time is acceptable though not
outstanding.
We do not use a lots of photos or canvas, just little pixmaps but
almost in every
widget. We suspect the main culprit in our case to be the 'frame'.
HTH.
PYLyon
Joe English
> [...]
> We have developped a theme with Tile. This theme uses
> a lots of small icons and graphical elements than are
> almost all as small as borders or lines.
>
> The overall result under linux is nice and pretty fast.
>
> But under Windows, we have to wait for something like 20-30s for the
> initial drawing of the main window and each time we switch
>
> We do not use a lots of photos or canvas, just little pixmaps but
> almost in every widget.
It's best to use large pixmaps for background patterns.
For instance even if it's only a 2x2 pattern, you should
create a (say) 256x256 pixmap, fill it with the pattern,
and use that to generate the background element.
It's faster to draw a big image a few times than it is
to draw a small image many times. The bigger the
"stretchy" part of the image element, the faster
things go.
--Joe English
pfradin
> It's best to use large pixmaps for background patterns.
> For instance even if it's only a 2x2 pattern, you should
> create a (say) 256x256 pixmap, fill it with the pattern,
> and use that to generate the background element.
>
> It's faster to draw a big image a few times than it is
> to draw a small image many times. The bigger the
> "stretchy" part of the image element, the faster
> things go.
>
> --Joe English
I agree with you in theory but in fact we define Labelframe.border
with :
ttk::style element create Labelframe.border image $I(border) \
-border 4 \
-padding 4 \
-sticky news
to have a pretty rounded Labelframe. 'border' image is a 15x19 GIF. If
I remove 'image' property in this 'element create' command, theme will
be quick ... but the appearance is bad (dark greyed instead of white,
all buttons are squared instead of rounded...).
--Patrick Fradin