![]()
You should still use feh's INTERNAL "-reload" feature to refresh the image every 10 seconds or 5 seconds or whatever you want (as I explained in my previous post). Not only is "auto-detect / kill / re-launch" somewhat complicated, but it would introduce an annoying screen flicker every single time the entire feh application had to be closed and re-launched from scratch.Ī better method is to DRAMATICALLY REDUCE the chance of feh catching an image file "in the act" of being written. Filemaker pro windows page faults code#But the code to do that would first have to kill the current instance of feh before re-launching a fresh instance of feh to display the newly-updated image. That way, only completed images would ever be displayed. ![]() One method would be to "auto detect" when 100% of the image file has been written - and only then trigger feh to display the completed image. Filemaker pro windows page faults full#If you opened the JPG file after a full 20 days, half the image would still be gray! That's not the fault of the image viewer - that's just the nature of the situation.įortunately, I have a solution for all of this. The "actual time spent writing" might only amount to 1/10 of a second, but the "total time to complete the write" would still be 40 days. Filemaker pro windows page faults software#Depending on what the software is doing and how it behaves, it could actually be a matter of "process 10%, write 10% process the next 10%, write the next 10%".Īs an extreme example, it could take 40 days to write a single JPG file if the processing component involved ray tracing a complex 3D model with photorealistic lighting. Writing a file can take a surprisingly long time - especially when you consider that writing a file isn't necessarily just "writing" a file. So if feh is reloading the same image every 10 seconds, for example, you might expect to see some amount of gray about 1% to 10% of the time. I of course have no clue what kind of "export script" you're using to generate the JPG file, but it could easily take a good chunk of a full second to complete the write. In the "few times" you saw an incomplete image, feh was almost certainly catching the image "in the act" of being written to the storage device by your script!įor example, if feh happens to reload the image at the exact moment only 70% of the JPG file has been written, then the top 70% of the image would appear normal and the bottom 30% would be gray (indicating "no data").įeh is doing its job perfectly - it's showing you EXACTLY what the contents of the image file look like at that exact moment! Let me start by saying that no image viewer in the world can fully display an image that does not fully exist! To understand the full context, please start here. The image display is controlled by my fehshow command. The image file is continuously overwritten at regular intervals and displayed on a large screen to show employees the live status of items at a warehouse. NOTE TO OTHER READERS: This person is using a script to export the contents of a FileMaker database to a JPG image. This may not be a question you can answer but here goes.Ī few times the bottom half of the display changes to all gray. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |