Exit program on OS Sleep/suspend

Submitted by Richard Yorke on Wed, 09/10/2014 - 09:18
Forums: 
Bug reports

I realise that there must be known problems that causes the program to crash if it goes to sleep as there is an option to "Exit program on OS Sleep/suspend" However, I have this selected and using Win7 64bit I still get a warning on waking .... “FRV: Fast RAW Viewer has  stopped working” if it was running before the computer went to sleep. The information given is :-
Problem signature:
 Problem Event Name:              APPCRASH
 Application Name:              FastRawViewer.exe
 Application Version:              0.9.3.361
 Application Timestamp:              5400434c
 Fault Module Name:              Qt5Gui.dll
 Fault Module Version:              5.2.1.0
 Fault Module Timestamp:              53102d07
 Exception Code:              c0000005
 Exception Offset:              0000000000245bea
 OS Version:              6.1.7601.2.1.0.768.3
 Locale ID:              2057
 Additional Information 1:              9044
 Additional Information 2:              90443cff63622688f8978888a6313f5b
 Additional Information 3:              8f86
 Additional Information 4:              8f8643b0a308465c340f5c6a9743fb5a
 

lexa

Wed, 09/10/2014 - 11:21

FRV tries to restore graphics state after awake (recompile graphics shader code, re-upload all the graphics data to card and display the image).

Unfortunately, this does work not for all graphics drivers, don't know why. So, the only solution for now is 'exit on sleep'. 'Exit on sleep' also may not work right (although I have not seen it in the wild) if your OS does not allow FRV time to terminate.

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Wed, 09/10/2014 - 11:22

Yes, but I have exit on sleep selected and it is still doing it.
 

lexa

Wed, 09/10/2014 - 11:24

See my extended comment:  FRV tries to quit immediately after receiving sleep signal from OS.



I'll try some tricks for faster exit, not sure these tricks will help.

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Wed, 09/10/2014 - 13:12

Sorry, I thought I had read it all, but looking back I realise I had not (I had just been stung by a wasp and it is stopping me concentrate as I should!)
 
It is not a great problem to me, I am just trying to find as many things wrong with the program as I can to help you speed up its development :-)
 
I find it happens on both my computers, the slow notebook (a Lenovo S205 with an AMD Fusion processsor at 1.6 GHx) and my home built box with Intel i5-3570K processor running at 3.40 GHz with on board Intel graphics. Both use Win7 64bit so that seems to be the common factor. However, all my other programs restart after sleeping. 

lexa

Wed, 09/10/2014 - 13:36

Thanks for bugreport.



I'll try to investigate the problem in depth, although your error reports points to Qt5Gui.dll which is out of my control (this is GUI toolkit we use). Hope, updating to newest Qt version will help.

BTW, what FRV version do you use, OpenGL or DX9?

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Wed, 09/10/2014 - 13:43

Open GL but I will install DX9 and see if that makes a difference.

Richard Yorke

Thu, 09/11/2014 - 15:36

I have now installed the DX9 version on both computers and they now both shut down FRV successfully when the computers go to sleep. It may be my imagination, but I also think that the quality of the image display is slightly better with this version, and this is on both machines, so it would seem to be software rather than hardware giving that improvement.

A point of interest is that the notebook uses the AMD Radion HD 6310M Which you list recommends the Open Gl version for, though my desktop uses the Intel HD Graphics 4000 for which you recommend the DirectX version.

While examining the images a bit more critically, I notice that the bottom bar is being squeezed a little too much to fit on a 1280 x 1024 display, and the text looks a bit big compared to modern software as well. I think it would look better on both counts using a font one size smaller. However, if you want to keep the same size, there is a small empty box on the extreme right that could be removed to allow a bit more space.

lexa

Sat, 09/13/2014 - 04:15

If you use some of hardware resample options ( http://www.fastrawviewer.com/usermanual/program-settings/gpu-processing ), it is possible that image qualtity slightly differs because of different defaults are used by hardware in different drivers (DX9 vs OpenGL).

Thank you for info, that DX9 version works better on your hardware.

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Sat, 09/13/2014 - 05:21

I should have mentioned that not only does the close program on sleep option work without any problems, I no longer need to use it as the program recovers after sleep without problems when using the DX9 version on both the computers :-)
I think that from my experience the recommendation of Open GL for most users could be a bit optimistic, especially when I have had problems using the Open GL version on a computer with the AMD Radion HD 6310M which would appear to come into the Radion HD2xxx - HD8xxx group that you specifically recommend the Open GL version for. Perhaps it would be better to suggest using the DX9 version first, as I think first impressions would be better with that, and then suggest that the Open GL version could be tried to see if it improves performance. Any problems would then be more obvious having seen how the program should behave while using the DX9 version. 

lexa

Sat, 09/13/2014 - 05:57

We studied many new things from our open beta-test. Most our initial test team members (closed beta-test program) owns mid- or high-end video hardware (because it speed-ups today graphic processing tools such as Photosop or CaptureOne). For this hardware OpenGL works very good.

Unfortunately for us, majority of real users (not professional digital photographers who invest much in computer hardware) uses low-end or CPU-builtin GPUs. Drivers for these hardware are not optimized for OpenGL usage, because no one plays OpenGL games (or uses OpenGL CAD applications)  on such hardware. So, yes, DirectX should be default option for FRV.

Unfortunately again, FRV requires up-to-date DX9 software (June-2010 DX9 is enough), but ever Windows 7 do not have DX9 so new (until 'recommended windows updates' are installed, this is non-default option for Win7, so most users do not install 'recommended' updates, only 'critical' ones are installed /and there are many non-updated Win7 installations too/).

So, we need to force DX9 upgrade on first FRV install. This is not good again, because Microsoft DXWebSetup (DX9 updater) requires internet connection *and* tries to install Bing toolbar until careful user removes checkbox (and, sure, there is no way to run DXWebSetup with this checkbox off by default).

We're working on it. We hope, we'll be able to deliver dual-mode version (DX9-OpenGL in single program binary) when GUI Toolkit we use (Qt) comes to 5.4 version (5.4-alpha was released this week, so 2-3 months and it becomes stable). We're working on not annoying user by DX9 reinstall when it not required. But all these little things requires extra development effort.

On the other side, OpenGL 2.1 (8 years old technology) *should* work on most today graphics software (the only exclusion is very old Intel 'chipset' GPUs). Unfortunately, it is not for many low-end graphics card. We know it now, after 4 months of open beta-test.

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Sat, 09/13/2014 - 06:52

I can certainly see your problems. My desktop is a fast computer, built because I wanted Lightroom to work smoothly. However Lightroom does not use OpenGL so I saw no reason to spend money on a fast graphics card and use the on board graphics. However, even if I had a fast card, I see the main use for FRV to be in the field on computers not fast enough to bother with OpenGL. I think if you are not careful you could end up getting sidetracked by beta testers with fast computers giving their views of what is best for them, when that is not the environment it is going to be used in. Given the choice I would use Lightroom rather than FRV. The reason FRV is so attractive is that I can use it on a machine that can't handle Lightroom and these are the machines you need to optimise the software for.
 
The market sector you are looking at is, at first sight, the same as Lightroom has aimed its Lightroom Mobile at. The difference being they think we want to be able to edit pictures already in Lightroom while away from our main computers. You and I think that being able to view, asses and sort the pictures, ready to edit them when we get home is the way to go. FVR also has the advantage that it does not require access to the internet (once installed) as it does not make use of the cloud. 
 
As for Win7 not having DX9, I think your option of auto installing DX9 is not going to be a problem for users already computer literate enough to cope with with Lightroom. You could possibly add a warning to untick Bing when you ask for DX9 to be installed. But to my mind problems at this stage are far less than trying to run with OpenGL when it is not really suitable.

lexa

Sat, 09/13/2014 - 08:10

I do not agree, that FRV should be used only on location with slow computer.

Just tested: on my desktop (CPU: i7-4770, 32GB RAM, fast storage) Lightroom tooks 3-5 seconds to build 1:1 preview (sligtly faster in batch preview creation mode) of 36Mpix Sony A7r RAW.

So, if I need to inspect yesterday session with, for exampe, 1000 shots, I'll either will wait about 1 hour for batch preview builds, or will waste 1-1.5 hours waiting for 'Loading...' Lightroom message. Sure, Lightroom caches 1:1 previews, so if I'll revisit same file it will be displayed much faster.

FRV shows these files at 6 frames per second on same hardware, so for 1000 shot I need only ~3 minutes (plus time for image inspection).

So, FRV targets initial sorting of frames shot, regardless of computer used (slow laptop on location or high-speed desktop at home/work). We're fighting against these 3-5 seconds (on high-end desktop) or ever 10-15 seconds (on slow laptops) for the frames you'll never see again (because 80-90-99% of all frames shot are crap).

So we provide tool for  a) fast RAW display  and b) fast technical analysis to drop crap frames by formal features (right exposure, right focus). All non-rejected frames may be imported in lightroom, previews generated (you'll save 80-99% of wasted time) and processed in usual way.

We need to target slow laptops without a doubt. But FRV shines on fast computers too.

 

--

Alex Tutubalin/FastRawViewer team

Richard Yorke

Sat, 09/13/2014 - 08:24

Fair comment! I suppose I have just learnt to live with Lightroom. Most times I am dealing with less than 500 shots at a time. I tend to import those and leave the previews being built while I unpack, rinse equipment and the like, so that when I actually get to looking at the results all the previews are cached and I have minimal frustration. My frustration is after Saturdays shooting, I have nothing to easily view and sort my pictures, and anything I do do has to be done again when I get home Sunday night, as nothing I do (apart from deleting the very worst shots) is carried over to Lightroom. To be able to look at the shots and save time when I get home sounds great, and enough in itself. I may well find when I start using it for real (I still have to do that!) that I will use it at home as well, as you suggest.

Add new comment