I’m just getting close to being finished with my new yber interface. BUT now I have a serious problem that the background don’t repaint when I move the interface fast enough. So it leaves irritating trails behind. Basically it looks like you are painting with the window in the viewport.
Does anyone have a clue how I could address this issue?
This is what the program does:
I have several dialogfloaters. When a button is pressed and the mouse is moved within one of the dialogs, this floater will be moved. The repainting is perfect as long as I only have 1 dialogfloater. However the problem begins when we have 2 floaters. I simply move the second dialogfloater when the first one is moved, so they follow each other. When this happens, the viewport will not be redrawn.
The strange thing is that if I use a normal “top toolbar” (the blue one in the top) to move the window, then it works fine. All the floaters move smoothly and everything is repainted. However I have already created my own “toolbar” in the top that I would like to use instead.
I tried a bunch of things to get around this problem, but nothing worked fine. For example:
gw.updateScreen() – nothing happens
completeRedraw() – well works, but is pure madness since it will force a complete redraw of all geometry which is slow.
Any ideas? Would suck to throw away my new interface.
/Andreas
Hey Andreas, have you tried something like this:
gw.enlargeUpdateRect #whole
gw.updateScreen()
The reason gw.update does nothing sometimes is because it has nothing to update, enlarging the update rectangle ensures that the whole screen gets updated.
could work.
CML
Cool!
That works, … almost.
It works in the active view, but if there are say 4 viewports then it only repaints the one that is currently active so the windows still paint if you drag them over the other viewports. Is it possible to updateScreen on all the others?
/Andreas
Yeah, try
redrawViewsfont=Courier New[/font]
Unlike complete redraw, it is intended to be more efficient.
edit: polyspeed looks really cool, i hope that the gui does not reduce the efficiency of using it!
Hi, unfortunately redrawViews() doesn’t do anything in this case. It’s very strange with the interface paint thing, sometimes it doesn’t happen for all windows.
“edit: polyspeed looks really cool, i hope that the gui does not reduce the efficiency of using it!”
Thanks. What do you mean efficiency of using it? Performance wize it’s not a problem, but it looks bad if the background isn’t repainted fast enough. The new interface has been created to make it easier to use the program, it also looks quite a bit nicer.
Here is a pic of it:
Thanks
/Andreas
Hey Andreas, the gw. functions only work in the active viewport as far as I know. You could try something like this:
nv = viewport.numViews
curview = viewport.activeViewport
for i in 1 to nv do
(
viewport.activeViewport = i
gw.enlargeUpdateRect #whole
gw.updateScreen()
)
viewport.activeViewport = curview
This is the same idea that the script Quickmaximize uses, probably my most used script.
It might not be efficiant to constantly check all the viewport though while moving. Maybe it can be ok if only the active view is updated. I know that I always work in a single viewport anyway.
CML
Haha, i tried that now and it was a BAD idea. The whole viewports shakes when the yellow rectangle moves around for switching viewports.
Damn, there must be a reason why it stoppes repainting. It’s annoying.
/Andreas