Control Flicker

Targets Windows
1

Hey guys,

As most people are aware; window builds tend to have flickering issues so hopefully this modules fixes it universally: http://www.sendspace.com/file/ei1vt0

Add it to the open event of a window via: Flicker.BeGone(Handle) such as

Flicker.BeGone(Window1.Handle)

Just looking to see if a few people are willing to test it out on an older project of theirs which had flickering issues? also sorts out the transparency issues too, so you can move labels etc around without parts of it duplicating in the background…

It is just a simple test for now, so it might change the window in an undesirable way, I just don’t have any largish projects at hand to test myself atm :/.

example:
http://www.youtube.com/watch?v=cdz31L9a62o&feature=youtu.be

(fullscreen /HD it)

2

Module doesn’t compile as there seem to be some things undefined

IF this is for windows only make sure it’s wrapped in #if TargetWin32 as well

3

[quote=13718:@Norman Palardy]Module doesn’t compile as there seem to be some things undefined

IF this is for windows only make sure it’s wrapped in #if TargetWin32 as well[/quote]
It is for windows only (so yes, one will need to wrap it in a target, sorry)

I’m assuming the above compile issue is ^?

4

well there seem to be some undefined values but since its encrypted I cant tell you what they might be

5

[quote=13722:@Norman Palardy]well there seem to be some undefined values but since its encrypted I cant tell you what they might be[/quote]Ah, it’s because I haven’t included the constants from my library!

Well, the code is:

Soft Declare Function SetWindowLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
  Soft Declare Function SetClassLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
  
  dim Void as integer
  
  Void = SetClassLongW (WindowHandle, -26, ctype(&h800, integer))
  Void = SetWindowLongW (WindowHandle, -20, ctype(&h2000000, integer))
6

Luke, I’d be interested in giving your module a try, but will need some additional info:

How should the above declares be defined? In a global module? In the window open event?

The idea looks very promising, but as it stands I can’t get it working at all.

7

[quote=18965:@William Koperwhats]Luke, I’d be interested in giving your module a try, but will need some additional info:

How should the above declares be defined? In a global module? In the window open event?

The idea looks very promising, but as it stands I can’t get it working at all.[/quote]
I think you can do it anywhere, even on an active & opened window.

I believe Xojo does register all the windows /class styles as soon as it loads, so you should be able to do it on the app.open event for every window. You’ll have to do it for every window you have though, so I’m guessing subclassing the window class and adding that code to it should suffice.

I’m still quite far from finishing a largish app I’m currently working on to extensively test it, but so far i’ve had a much better experience with this set.

8

For anyone playing along at home, see my post in the Windows Flicker in the IDE thread for more information on the situation and these “magic” declares.

10

Luke, I’m willing to give you the benefit of the doubt for now, but even with the following code in the Window.Open event

  If TargetWin32 Then
    
    Soft Declare Function SetWindowLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
    Soft Declare Function SetClassLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
    
    Dim Void as integer
    
    Void = SetClassLongW (Self.Handle, -26, ctype(&h800, integer))
    Void = SetWindowLongW (Self.Handle, -20, ctype(&h2000000, integer))
    Flicker.BeGone(Self.Handle)
    
  End If

It still gives a “This file doesn’t exist” error (File: RBXML; Location: “Flicker.Begone”),

11

Try without Flicker.BeGone :stuck_out_tongue:

[code] If TargetWin32 Then

Soft Declare Function SetWindowLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
Soft Declare Function SetClassLongW Lib "User32" (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer

Dim Void as integer

Void = SetClassLongW (Self.Handle, -26, ctype(&h800, integer))
Void = SetWindowLongW (Self.Handle, -20, ctype(&h2000000, integer))

End If[/code]

12

That “worked” (i.e. there were no compile errors), but the flicker was worse than ever! It did fix the weird control refresh problem that I mentioned in a different thread (See here), but at least on my Win7 Parallels virtual machine (full screen on a MBA) it was worse overall. Maybe I’ll put in a preference and give Windows customers a choice of which poison they would rather swallow :slight_smile:

Cheers.

-bill k

13

I have a window with about 30 container controls in it. Each container control has a custom slider and a few labels. There’s also a custom canvas control. This window has always had awful, awful flickering under Windows when being resized or scrolled, and under some circumstances when the sliders are operated.

I just pasted Luke’s code as reposted by Norman into the Open event, and… the flicker is GONE! Oh Happy Day.

There are some new and pretty bad drawing anomalies happening in my scroll bars now but this is really promising. Thanks, @[deleted] !

14

Oh yeah, and the container controls are inside GroupBoxes. Normally I would have edited my post to add this info, but I got locked out like within 80 seconds of posting :frowning:

15

[quote=19621:Norman Palardy]Try without Flicker.BeGone :stuck_out_tongue:
[/quote]
Tried it , and it did seem smoother, but I noticed a couple of graphic anomalies. Then I closed my application and as soon as it quit, my CPU started racing to 100%, the mouse locked up, then the whole system blue screened. The reboot has about 45 agonizing seconds longer than its normal reboot. This sytem is 2 years old and has never blue screened before tonight. Perhaps just a coincidence, but will not be trying this code again.

16

As Joe told, beware of magic declares. :wink:

Let’s wait to check how mature R2 will be about this subject, as stated by Geoff.

17

[quote=19620:@William Koperwhats]Luke, I’m willing to give you the benefit of the doubt for now, but even with the following code in the Window.Open event

It still gives a “This file doesn’t exist” error (File: RBXML; Location: “Flicker.Begone”),[/quote]

The exported code didn’t have my API module included, so I gave the raw declares later on. Had Xojo forums allowed users to edit their posts I would of removed the link /code from the Original post to avoid confusion. Just ignore the initial post /download.

[quote]As Joe told, beware of magic declares. ;)[/quote]It’s not even a magic declare, it’s an extended window style that windows added to address flickering issues which was implemented and supported for all windows versions after windows 2000?

You still need to handle all the paint events in WM_Paint for it to work correctly, which xojo may or may not do.

You need to disable Own /Parent device context which is what the first declare does while enabling Savebits, otherwise it’s ignored even if you do successfully set it. There were also some other scenarios where it simply would not work, so something as simple as adding in a certain xojo control could break it.

I’m guessing it’ll still flicker if you have “erase background” set on controls and why erase background is on by default is beyond me.

I’m unaware of whether Xojo’s double buffering option on controls causes any issues.

You can also try enabling or disabling GDI+ to see how that interacts. GDI & GDI+ both I will point out are deprecated and post-windows XP, it switched from GPU to software processes and are slower.

With the above in mind, that’s why it was given “as is” to be tested. Xojo does not make their internals available to users so you can not meaningfully alter core code that affects the entire framework otherwise you might as well just buy the console version of xojo and implement it all yourself. This is simply a minor, intermediate work around.

Some controls may render “oddly” (or to better elaborate, since they now render strictly bottom up) so you have to keep that in mind with layout.

18

This is very promising, although I’m concerned about what I don’t know. Will have to look into these declares. That said this bit of code dramatically reduced the issues with labels showing their bounding boxes on mouse over. That’s a good start! Wish I had known about this years ago.

While I’me very happy with the performance of my XOJO Mac project, i’m continually disappointing with the UI compromises on the Win side. Just clicking maximize in the XJOJO IDE on my Win 8 i7 solid state computer takes 2-3 seconds for the controls to refresh and the window to redraw. I consider that unacceptable, and demonstrates the problems I have with my app. I’ts been so bad at times that I’ve considered leaving Real because of the challenges with the Windows framework, but I’m fully committed now.

I accept all the reasons, but the reality is that I need to be able to present a professional UI to Windows clients and there are times when that becomes a challenge.

The Talk of moving to .NET I think is encouraging. In the mean time I think that the community needs to pull together to try and compile as many tips and tricks as possible to improve things. Luke I really appreciate your work here and if you have any more info to share please let me know. I have a 75K line project with a very complicated UI that I would be happy to leverage to help test any other tricks you might have.

19

[quote=20094:@Julian Mussi]I really appreciate your work here and if you have any more info to share please let me know. I have a 75K line project with a very complicated UI that I would be happy to leverage to help test any other tricks you might have.[/quote]Apart from enabling composited and ensuring you have controls nested and what not there’s not much one can do from a xojo user’s standpoint since you need Xojo’s built in classes such as windows and controls’ source code to be opened up to have any real chance.

The only other thing I can think of is registering a custom winproc (or whatever its called) on the window to filter out all the WM_Paint messages from reaching the xojo framework so you can handle the paint event yourself, but that could get complicated and messy really fast as well as destroy that cross-os aspect and work flow since you need to edit the underlining source.

Probably fine if you’re just targeting windows and dont need cross OS, but then you might as well just buy the console version and write your own UI framework

20

I’m having the same issue. It is unfortunate because it does take care of the flicker all over the place when testing, but then I close a window and the CPU starts racing followed by the computer crashing. :-/

Alas…

21

Exactly the same thing happened to me. I analyzed the minidump and nvidia’s graphics driver was the faulting module.