I am testing some plugins I made for Synfig which means that I use the plugin feature a lot, but each time I activate a plugin the size of the canvas screen changes which forces me to resize the window and that gives the notorious resize bug as a frequent result. Alt-tab combination does not always work and leads to crashes half of the time and that leads to the usual frustration and the occasional rage quiting Is there a way to prevent plugins to change the size of the canvas window?
We cannot control the default size for newly created documents unless we force it to be a fixed value. Fixed values are good in some situations and bad in others, so in general for new documents, we leave that the windows manager choose the default size of the new window.
I think it could be possible to grab the position and size of the document window before it is closed and replaced by the new one, and then apply those values to the new created document
It wouldn’t solve the resize bug but would avoid to trigger it.
Without wanting to put doubts over your work-flow, is it strictly needed to resize window to test if the plugin worked? Maybe you just need to fit zoom to window and see the results. Using the Navigator also helps on those cases where available size is not enough to show what you want.
Also, have you tried to disable single thread option? resize bug is not triggered in that case and I don’t see lately the windows version so unstable with it enabled.
(Heavy voice…) You dare to question my workflow…?! Moewhahahaha!
Anywayz, I forgot that I was working on the latest development version, because I wanted to try out the new cool tangent system and for some reason the file I was working on crashed all the time when I loaded it in Multithread, so I had to enable single thread (which I normally never do, because why would one walk on one leg if you have several ). Also the navigator crashed when using it. Hence all the formentioned problems. To keep my sanity I downgraded back to the official 0.64 version and everything works fine again.
In the end though it would be nice for the plugin to keep the size of the original canvas window after it was executed.
hi darkspace65, does that mean that with the last dev snapshot you found regression or i misunderstood ? i that the case, please, can you report it ?
Well, in the last dev snapshot, most of my files refused to load in Multithread, aka single thread disabled. The size or complication of the files did not seem to matter. I got a hickup in the system with single thread and Cairo enabled (a system hang of two seconds every 10 or 15 seconds or so) . Stickman plugin did not work and made the system hang or crash and using the navigator with or without Cairo enabled in the navigator evoked a crash and alt-tab during the resize bug did not work. I think that sums it up. Mind you, I happily continued to work with the official version.
Outch!!! i hope 0.64.1 stable on windows will be at least stable as 0.64.0. I know it’s not useful for you, but, from debian point of view pre-0.64.1 look like more stable than 0.64.0 !
I’m very concerned with the Cairo troubles in Windows version. Looks like in windows, the new Cairo render method makes system render slower. I don’t know what could be happening. Remember that code for Cairo render is the same in all platforms, so I only can make guilty the way each platform library implements the code.
Also, for all platforms, the current Cairo render method is not optimized for tile render. It s a waste of time to prepare a new Cairo Context for each tile if at the very end Cairo is not using the tile clipping benefit to increase render speed.
Maybe one general benefit would be disable tile render when rendering in Cairo. In any case the preview render doesn’t use tile render and is still slower than software in render time in Windows.
So for Windows users I recommend to disable Cairo render. It won’t help