I'm currently using the JavaFX ScrollBar control, which in itself works fine - however I'm not satisfied with the "animation" of the thumb when dragging it.
More specifically:
When I drag the thumb quickly, fast acceleration that is - the thumb animation doesn't follow immediately, but kind of "lags" behind - same behavior when I stop dragging the thumb... it takes a split second before the thumb really starts / catches up to it's intended position.
It's not an issue of heavy layout calculation or so, because I'm experiencing the same with just rendering the ScrollBar alone without any content.
Is there some option to make this "acceleration animation" / "lag" go away? - I haven't been able to find any property to set as of yet.
Thanks,
Set the flag "-Djavafx.animation.fullspeed=true" as part of the startup command via the command line. (Note that you can't do this via "System.setProperty(...)" within the application startup...)
Related
When I double-click on an animator controller to launch it, the animator tab appears, but when I run the editor, I don't get the usual flow, operations, etc... I only get a static view of the states and transition arrows between them. My parameters do not show the changes they go through either.
I have multiple animations and can switch between them when certain game conditions occur, but nothing really shows when I do so, to see the flow of control, what happens, what goes wrong, the switching, the progress bar, etc...
I have the latest Unity 5.2.0f3 so I wondered if it is just me or others are having a similar problem...
What we need to do is this: Once we hit the play in the editor mode (and have the animator window docked on one side, of course) we just go and click the object in the hierarchy for which we want to analyse the animation flow. And the animator window will start showing the states and the progress bar.
Also, after upgrading to Unity 5.2, it is worth checking the values that were previously set for transition states, for example if vSpeed is greater than 0.1 then start walking. All my set values were messed up; i.e. changed.
It is possible to use the SetWindowPos API on Windows to keep a windows always on top of other windows, and there are many questions on StackOverflow dealing with this.
It is possible to keep only part of a Window always visible? I.e. specify a clipping region inside an existing window, and keep only that part visible?
A use case would be the following (on Windows):
User clicks on icon to run app.
User highlights a portion of the screen to focus on (similar to the Snipping Tool on Windows 7)
The highlighted part of the screen remains always visible, even when other windows/programs are moved over the selected region.
I know the issues that would spring up with having other applications that are also set to being topmost. Just curious if this is even possible?
Even if you change part of your window to be transparent to what's below (with a clipping region) it's still going to take all the mouse clicks, etc. that occur over the transparent part.
Your best bet is to create a new smaller window and make it top-most while hiding the main one.
I want my frame to be always on top, but I want it to be really on top. I want no other windows to hide it, even if they are also "always on top". I'm using wx.STAY_ON_TOP and wx.FRAME_FLOAT_ON_PARENT, but still there are windows that appear on top of mine. Also, the taskbar appears on top of my frame, while I'd like it to be behind my frame.
I've tried a lot of things that didn't work, detailed here.
Any idea how to make my frame really on top?
Because their is no standard method in doing so, as it is most often an undesired effect, you can possibly achieve this by frequently setting the topmost flag again to "overrule" any other applications going for the topmost position. You could do this using a timer which sets the value every x ms, or you can try and only set the ontop flag again when the window has lost focus. The events to set the ontop flag are:
EVT_SET_FOCUS
EVT_KILL_FOCUS
Try using this:
wx.Frame.SetFocus()
Basically, the problem concerns border flickering during window resizing on Windows.
My first goal was to repositioning controls on a dialog during resizing of it.
I think I got a good dynamic repositioning without almost any flickering during this operation, but here I'm talking about main window border flickering.
However, I wasn't able to eliminate it at all.
To simplify the example try to create a simple win32 app with default code VS provided.
I'm testing it on Window 7(64bit) with the default theme (Windows 7 basic, no transparency) and VS2008.
1) Do not add code to the app.
2) run it in debug mode.
3) Drag the left edge of the window slowly toward the left of the screen and at the same time keep an eye on the right edge border of the window. You should see a redrawing taking in action.
4) Repeat step 3 moving rapidly the mouse, you should see the flickering on the right edge more clearly.
If you invert the edge, that is moving the right edge of the window, then the left edge stay firmly there without unpainted regions.
The same process happens for the top edge border vs. the bottom one.
Now, enable he Classic Theme (that similar to Win2000) and repeat again the steps above. The right edge is perfectly there without flickering at all!
If you keep an eye in the Output Window of Visual Studio when you run in debug mode you should see a list of dll loaded together with your exe. If you run in debug mode with the default theme you will see uxtheme.dll loaded. On the contrary, with classic theme enabled the uxtheme.dll is not loaded (dwmapi.dll is always loaded). Probably uxtheme.dll is loaded at runtime, based on desktop settings and it takes in action for redrawing your windows non-client area.
Another trick you could use to see the effect of this flickering is to add a case for WM_NCPAINT and return 0 instead to call the DefWindowProc(). Repeating the steps above and moving fast you should see a big part of the right edge of the window completely erased by background windows. This doesn't happen for the top and bottom ones.
Any idea to resolve this flickering?
Thank you!
UPDATE 2012\09\04:
- With Windows Classic theme:
uxtheme.dll is loaded at startup, but dwmapi.dll not. Uxtheme.dll, however, seems
not involved in any window rendering process. The window resizing is perfect.
- With Windos 7 theme (transparency on borders):
uxtheme.dll and dwmapi.dll are loaded at startup. Uxtheme.dll seems not involved in
any part of non-client area except some from the top of the window and the main menu.
But I'm not sure of the last. The window resizing is perfect.
-With Window 7 Basic theme:
uxtheme.dll and dwmapi.dll are loaded at startup. Uxtheme.dll is heavily used in the
rendering of non-client area. The windows resizing is bad.
We have a fairly complex GUI, so when certain windows are resized their Redraw() is set to false till the operation is completed. The problem with this is that if the OS "Show window content while dragging" setting is checked, when decreasing the window's size the windows behind it are not repainted. This means I have to force the repaint myself so the remains of the resized window are deleted. I have no problem getting the dimensions of the region that was uncovered. What I'm looking for is best way to cause all windows within that region to repaint their part.
Not being much of a GUI programmer, I can traverse the uncovered region and list the windows in it. Then, I can ask each one of them to repaint its part. But I'm quite certain there has to be a better way to do this...
It is worth mentioning the app is written in PowerBuilder. This means I can call whatever Win32 function I'd like, but have limited control over the GUI behavior and the message handling. If there's a better way to prevent the window's content resize from being visible, or there's a way to make a non-redrawn window clean after itself, I'd love to hear it (just have the limitations above in mind).
I'm curious what version of PowerBuilder you are working in? I do resizing all the time and never run into issues like you are describing.
Maybe you can lay out some more detail on why you need to set your redraws to false within the PowerBuilder environment.
Hope I can help.