fet 5.30.3 compiled from source on Manjaro16-06.
The 'Generate timetable' window gets corrupted after switching to another desktop and coming back.
do you have got a new computer or do you updated your video driver? (because it got similar bugs in the past with other software and it was "just" a problem of the video driver.)
well.. no... my computer il 2 years old and video drivers don't give me trouble at all
sadly i don't know wht do do, because we don't code "repaint" or something like that. That is all done automatically by Qt and the video driver. So i fear we must report it Qt. But they will have problems to fix it,if they can't reproduce the bug. I can't reproduce the bug. It is working fine here with windows 10, vista and Linux.
Switching desktops is tricky with FET. Try to restore the default settings (from the Settings menu or by the method from the README near the end - uninstalling FET completely), and use a single desktop for FET.
Thanks for your replies.
I found that just switching the windows full-screen and then back restores it correctly - so I wiil do when I need to refresh.
Reading this thread reminds me of a (very minor, but possibly related) issue with the Mac version. The time required to generate a timetable that is completely locked can vary considerably, depending on whether the app is running in the background (and not displayed), or running in the foreground.
With the app running in the foreground, it takes about ~25 seconds to generate. If I start generation, then switch to another app (say, a browser, that covers the FET interface), it can generate in as little as 2 seconds.
Given the comments here, I'd guess that this is also a Qt/video driver thing, maybe associated with the redrawing required to update the placed activities counter. I've attached a couple of screenshots (these were just generated, and are typical for the scenario described here).
I think that this is probably not an issue with normal timetable generation, since in that case the timetabling algorithms would be the limiting factor, rather than screen redraw.
Maybe you could send me this file (by email if it is private), so that I can do the same test on GNU/Linux and Windows.
It should not be that much of a difference in the generation times. Maybe it is a Qt problem.
Probably for real (unlocked) timetables the time difference would be very small.
Hi Liviu, I've just now sent that file to you in an email.
I checked under my GNU/Linux and Windows 7. The time is 4-6 seconds (5 seconds more often), does not matter if I keep the window in the foreground or background.
i can image only 2 things:
1. you tested with different seeds and there migth be a very difficult seed.
2. while you done FET into background, you at an other activity open that use all cores. Maybe you watched a video and the video player used all you cpu cores. so FET was sharing it with other software.
This result is reproducible (and is something that I've been noticing for some time now—I think I first noticed this after installing one of the more recent operating systems, possibly Yosemite or El Capitan). Since it doesn't seem to affect the time taken for "real" timetable generation (as far as I can tell), I hadn't paid much attention to it.
A simpler way to generate the timetable quickly is to immediately hide (Command+h) the FET app after starting the timetable generation, so it's not necessary to switch to another app to produce this issue. It really seems to depend only on whether the FET window is showing or not.
I've tested this now on my current Macbook Pro (mid-2014) and old Macbook Pro (early 2008), and both exhibit this behaviour. The test results included above were on my newer laptop, the results attached below are from the old one.
I've also tried this on the newer laptop with the discrete graphics card enabled (NVIDIA GeForce GT 750M) and with integrated graphics (Intel Iris Pro). All exhibit this same behaviour, so it doesn't seem to affected by the video card used.
i wasn't thinking about the video card. i was thinking about videos, which might do some high cpu load (of the video cards can't do all calculations).
but your reproductions are intresting. i will recheck it here now also. but i i don't know how to fix it.
Just to follow up on the Mac refresh issue, I've just installed the new Mac operating system (Sierra) and this problem is fixed. Looks like it may have been related to the operating system after all.
Thanks for letting us know!
So, I have the same problem: Timetable generated in foreground: 17sec; in the background: 1sec.
Is it a patch for Mac Os X El Capitan?
I definitely don't have the technical ability to fix this issue, and it seems like the problem exists between with Qt and El Capitan (also, I think, with Yosemite).
If it's possible for you (and I know that it isn't always an option), I do recommend upgrading to Sierra, which has fixed a few issues for me in addition to this issue with FET.
With version 5.30.5 compiled by me on Mac OS X El Capitan and Mac OS X Lion either with QT 5.6.1, I have two different result.
With El Capitan I have the issue reported by Darren McDonald with different time (more) in foreground and (less) in background. With Lion I have the same time.
ok. so it look like it is a problem of the task manager of macOS.
maybe it just reduce the priority. (even this shouldn't be critical if you didn't run other "critical" software; but maybe your os is busy with calulating indexes, ...)
under linux and windows it is possible to change the priority over the task manager. i guess it is also possible with macOS. please setup the default value there. don't allow the os to reduce it.
if that doesn't help you should write a bug report to apple.