Title

Message

Confirm

Want to earn a free DisplayFusion Pro license? We're looking for DisplayFusion translators!
<< DiscussionsReply

Button issues

Avatar from Gravatar.com
benway
342 discussion posts
Hey, great addition! Some things I've notice so far:
The buttons lag behind when you move a window (probably stating the obvious) (see pic)
It would be nice to have a single button for scooting the windows from one monitor to the other. (when you have only two monitors, you don't need a "next" or "previous".
It would be handy to be able to "move up" or "move down" the newly added buttons in list to show in the order you want on the taskbar (see pic)
• Attachment: button Movet.png [5,165 bytes]
button Movet.png
button Movet.png
• Attachment: button Scoot.png [17,166 bytes]
button Scoot.png
button Scoot.png
Jun 24, 2009  • #1
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with. :)

The "Next Monitor" button does move it between both monitors, or are you asking for something different?

Button ordering is on my to-do list for the next beta.

Thanks!
Jun 24, 2009  • #2
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with. :)

The "Next Monitor" button does move it between both monitors, or are you asking for something different?

Button ordering is on my to-do list for the next beta.

Thanks!


Jon, I suppose we just need a different icon for when you just have two monitors and you're just using one button to go in both directions. Something like [].
Also, the buttons look like they're a pixel low. :wink:

Great work!
• Attachment: button low.png [2,217 bytes]
button low.png
button low.png
Jun 24, 2009  • #3
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
Once the button designs have been completed by the talented Chris Ysebert, then we can critique them. He has some great ideas in mind, and they should be ready in the next few weeks. The reason it looks 1px too low for you there is that you are using a button that doesn't match your theme. I'll include a button for the Zune theme (which I believe is what you're using there, but correct me if I'm wrong)
Jun 25, 2009  • #4
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
Once the button designs have been completed by the talented Chris Ysebert, then we can critique them. :) He has some great ideas in mind, and they should be ready in the next few weeks. The reason it looks 1px too low for you there is that you are using a button that doesn't match your theme. I'll include a button for the Zune theme (which I believe is what you're using there, but correct me if I'm wrong)

Yep, Zune. :-) (see, seems to be a very popular theme...)
Jun 25, 2009  • #5
Avatar from Gravatar.com
benway
342 discussion posts
Buttons overlapping on Google Chrome using XP... (see pic)

Tough one, since Chrome has the Vista/W7 spacing even on XP.
• Attachment: googly.png [7,536 bytes]
googly.png
googly.png
Jun 26, 2009  • #6
Avatar from Gravatar.com
Apollo29
23 discussion posts
Skype 4.1 Beta also has an overlap problem with the button on Windows 7.
• Attachment: Skype 4.1 beta.png [4,746 bytes]
Skype 4.1 beta.png
Skype 4.1 beta.png
Jun 28, 2009  • #7
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
Skype 4.1 Beta also has an overlap problem with the button on Windows 7.

Let's blame Skype and Chrome. :-P I wonder how Skype would position it's button if the DF button was there first?
Jun 29, 2009  • #8
Avatar from Gravatar.com
Apollo29
23 discussion posts
More than likely the same way it did in the screen cap
Jun 29, 2009  • #9
Avatar from Gravatar.com
benway
342 discussion posts
MS Office communicator = not standard title bar style or size:
• Attachment: communicator.png [2,795 bytes]
communicator.png
communicator.png
Jun 29, 2009  • #10
Avatar from Gravatar.com
Atroos
13 discussion posts
Quote:
The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with. :)

Any chance of an option in the near future to choose the hit on system performance if a user wants, so it doesn't lag behind?
Jul 2, 2009  • #11
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with. :)

Hmm, it seems I'm seeing something quite a bit longer than 500ms to 1000ms delay. I can quick grab a window and scoot in to the other monitor and still see the DF buttons stay behind on the other monitor. Seems nearly a second...
Jul 2, 2009  • #12
Avatar from Gravatar.com
Kevin F.
438 discussion posts
1000ms is a second . as long as they don't float for 2 seconds its nothing to really report.
Jul 3, 2009  • #13
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
1000ms is a second . as long as they don't float for 2 seconds its nothing to really report.

Haha, good one. milliseconds does sound like so much less than a second. :-P Guess I should have googled up a conversion table.

But, I'm afraid this noticeable lag is going to be pointed out as a flaw by reviewers, because it does seem like something's wrong (thus my reporting it). I'd consider going the other route of sticking them solid if the performance is negligible. I'm not criticizing this great product (Jon knows I've been here since early on supporting it), but trying to help make it better.
Jul 4, 2009  • #14
Avatar from Gravatar.com
Kevin F.
438 discussion posts
Right with ya benway, I'm one of the longhauls too remember? Lol.

I just figured Jon had his ideas for them that would reduce that lag, but for now its to be expected.

Anyone know how fast ultramons buttons move? We can do better than them in everyway!
Jul 5, 2009  • #15
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
Thanks for the encouragement everyone. I will be working to reduce the lag, but I want to avoid polling more frequently (performance) or hooking individual windows (performance/stability). I'll keep everyone posted if I come up with a good method.
Jul 5, 2009  • #16
Avatar from Gravatar.com
Kevin F.
438 discussion posts
has anyone played with ultramon? How fast does it update? Jon should be able to match them within reason.....
Jul 6, 2009  • #17
Avatar from Gravatar.com
Apollo29
23 discussion posts
I would like to note that in the latest beta that Skype is worse than before. The custom button from display fusion covers the close button within Skype. Please review attached picture. I would also like to note that DF doesn't even try to draw its custom buttons on Office Communicator in this latest build? Nice job with the new buttons by the way. They look very good.
• Attachment: Skype.png [5,134 bytes]
Skype.png
Skype.png
Jul 6, 2009  • #18
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
I would like to note that in the latest beta that Skype is worse than before. The custom button from display fusion covers the close button within Skype. Please review attached picture. I would also like to note that DF doesn't even try to draw its custom buttons on Office Communicator in this latest build? Nice job with the new buttons by the way. They look very good.

Office seems to be it's own beast... :-(
• Attachment: office_DF.png [7,440 bytes]
office_DF.png
office_DF.png
Jul 6, 2009  • #19
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
Thanks for the encouragement everyone. :) I will be working to reduce the lag, but I want to avoid polling more frequently (performance) or hooking individual windows (performance/stability). I'll keep everyone posted if I come up with a good method. :)

Jon, if you stay with the current implementation, I might suggest turning the buttons off during a drag and then back on when the window is stopped (if that's possible for the current window only). This would hide the perceived lag problem. (just a thought)
Jul 6, 2009  • #20
Avatar from Gravatar.com
sfwrtr
212 discussion posts
Quote:
The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with. :)


[size=1](XP SP2 3.62GHz 4GB RAM v3.0.102 updated)[/size]

I'd like to vote for a performance option, here. The caption icons are much too lazy when redrawing. Distracting, in fact. I'm guessing they are a floating topmost level window. When something happens quickly, you get a momentarily overlay. For example, I use the auto-hide feature of the task bar (yours and Windows). See the picture. Moving a window quickly causes the icon to chase the caption, like the Windows mouse-tails feature.

I like the feature, but wouldn't use it the way it behaves now.

Last, do you really want to use the generic term titlebar? Under Windows, this part of the window is usually referred to as the caption.
• Attachment: lazyicon.JPG [32,571 bytes]
lazyicon.JPG
lazyicon.JPG
Jul 7, 2009  • #21
Avatar from Gravatar.com
PeterDackers
44 discussion posts
Although you are right about the term caption, I think titlebar speaks more to itself. Especially to people who's native language is not English? Just a thought. :)

And I wouldn't call the redrawing distracting to be honest, yes it's noticeable, but that's it. Maybe a good idea would be like 'benway' suggested? Turning them off while dragging. On the other hand you could go completely bananas and let the user type in a polling rate, but I'm afraid a lot of people will then change it to '0' and start complaining. :P

Sorry I can't add anymore than that Jon, the latest Beta seems to be running fine over here after I've excluded some applications from the titlebar buttons. For example: ZBrush. :)
Jul 7, 2009  • #22
Avatar from Gravatar.com
sfwrtr
212 discussion posts
Maybe I ought to clarify what I consider distracting: Something that moves asynchronously to what is being moved, that is, two different movements when you expect only one. Whilst turning off the caption button when dragging a window would work, it doesn't fix the problem when the task bar drops down over the window caption and the button (appears to) slide on top of the task bar.

That said, and as Windows programmer to Windows programmer... it just looks amateurish. I would rather not enumerate the number of times I've been told to fix a behavior that I thought wasn't that bad. :cry: (Of course, a few of them were genuine Windows behaviors, but that was a different battle.)
Jul 7, 2009  • #23
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
I completely understand, and I always hate things that seem half-baked. I am very happy to report that the button lag is completely gone in the upcoming Beta 3. I spent ~15 hours last weekend re-writing the entire hooking system to support this new feature. I am now using global hooks to update the titlebar buttons in realtime, with 0 lag. Because the hooking has proved so fast I was also able to reduce the poll frequency from 500ms to 1250ms, which has actually resulted in a performance increase despite the hooks. Good news all around. The only time that the hooks don't work is a 32bit application running under a 64bit version of Windows. This is something I just can't work around, unfortunately. DisplayFusion is running as a 64bit process (on 64bit Windows) and can't load a 32bit hook DLL. I am trying to resolve this issue, but it will take some real voodoo magic.
Jul 8, 2009  • #24
Avatar from Gravatar.com
benway
342 discussion posts
Bravo on the titlebar buttons. Virtually no lag now (except when you click for a window to jump to the next monitor the buttons are left behind for a split second - but livable ) They still float around slightly when you wiggle a window, but no one is really going to notice the movement now. Great job! Keep doing that VooDoo that You Do...
Jul 9, 2009  • #25
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
Indeed, much of it is voodoo magic... especially in x64 versions of Windows. When you say they hang around for a split second, are we talking about 50ms, 500ms or 1 second?
Jul 9, 2009  • #26
Avatar from Gravatar.com
Kevin F.
438 discussion posts
I don't see any lag for jumping...

Something a little unrelated though: Holding the move to next monitor shortkey still queues infinity, aka holding it resulting in a moving window for a while.
Jul 9, 2009  • #27
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
@pyrobob: There isn't much I can do about that. If someone wants to move the window that many times than more power to them.
Jul 10, 2009  • #28
Avatar from Gravatar.com
Kevin F.
438 discussion posts
Eh? No way to make DF not listen after its held for a second?
Jul 10, 2009  • #29
Avatar from Gravatar.com
benway
342 discussion posts
Quote:
Indeed, much of it is voodoo magic... especially in x64 versions of Windows. :) When you say they hang around for a split second, are we talking about 50ms, 500ms or 1 second?

Oh, barely noticeable. Maybe 100ms.
Jul 10, 2009  • #30
Avatar from Gravatar.com
PeterDackers
44 discussion posts
I thought I'd open a reply here, didn't want to open a completely new topic regarding some issues with the buttons. After all, this topic is called 'Button issues'. :)

First of all, the lag of the buttons is gone, the buttons look great with the new mouse hover and I totally love them. Better yet, how could I've ever done without them? Very nice job Jon!

I did however found some strange behavior while dragging the Task Manager under Vista. (It also happened in Beta 03, but then I saw you released Beta 04, so I gave that a spin first). When I open the Task Manager in Vista, all is fine. But as soon as I click the Caption bar or drag the window slightly, the buttons seems to disappear under the window and loose their functionality. (Shown in the attached screen shot). It's highly repeatable as it happens every time I open the Task Manager. Anything you want me to check on this end? Let me know. :)

Windows Vista Home P. OEM. 32-bit.

[sup]/Edit: added my edition of Windows.[/sup]
• Attachment: task_manager.png [28,827 bytes]
task_manager.png
task_manager.png
Jul 10, 2009  • #31
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
@pyrobob: I decided not to rate-limit the HotKeys, in case someone comes up with a use for wanting a repeating one. If you don't want it to repeat, don't hold the keys down. :)

@PeterDackers: Sorry, that is a known issue. :( It isn't specific to Task Manager, it will happen with any window that is "always on top". I'm trying to have it worked out for Beta 5. Thanks!
Jul 10, 2009  • #32
Avatar from Gravatar.com
grisham
2 discussion posts
Quote:
Jon, I suppose we just need a different icon for when you just have two monitors and you're just using one button to go in both directions. Something like [].


I second that!
Looking forward to the final button designs.
Jul 15, 2009  • #33
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
Just waiting for 1 more button, should make it into Beta 8.
Jul 19, 2009  • #34
Was this helpful?  Login to Vote  Login to Vote
<< DiscussionsReply