delay and Windows

edited November -1 in General Discussion

Hello all,
Our church is finally going to bite the bullet and get a projector. My two questions are this.
1. We will be purchasing a new computer. Will openlp 1.24 run ok on Windows 7 or should I look for XP?
2. While experimenting on my computer there seems to be a delay changing verses live and using a background theme with a picture. There is not a delay if I use the solid background. My computer I have been experimenting with is not underpowered. My question is, is this a hardware issue with the computer or software issue? Are there recommendations for a computer to purchase, hardware wise? I am still debating a desktop or a laptop?

I am looking forward to getting this all goiing. I personally would rather use Linux since that is my primary operating system but that would add more confusion for the operators and 2.0 is not quite close enough.
Thank you for the software.
Blessings
John

Comments

  • edited April 2010

    I think for future-proofing, it would be hard at this stage to recommend going for XP unless this machine is only ever going to be used for openlp v1 and/or you don't mind upgrading it to Windows 7 in the future.

    v1.2.4 does run on Windows 7, we do so at our Church. In some circumstances a few workarounds have been necessary, but I've not heard of a case where we didn't get it working. This post has a few comments on the subject. But compatibility modes or UAC tweaks usually get it working in the end.

    We have had a few reports of slow slide changes, but it only affected certain machines and we've never found the cause unfortunately. I've run it on prehistoric machines with cheap-onboard graphics with great response.  I vaguely recall a mention that older versions (1.0.0 or 1.0.1 I think) didn't have these issues but the developers couldn't find any differences in the code that could explain it. Ensuring the second monitor resolution is only as big as needs to be (e.g. 1024x768) and resizing the theme image accordingly may well help.

    We don't recommend hardware, I just suggest avoiding the really cheap end since they aren't going to do multimedia very well. If it comes recommended for Windows 7 "Basic" or has a Celeron chip, run a mile! If you plan to run openlp v2 in the future, then the more memory the better.

    In the past I would have recommended laptops just because they have dual-screen support built-in and they are often geared around presentation. However multiple monitor support is now getting more widespread in desktop machines too. It really depends on space, portability, how you plan to use computer and if you think you might want to upgrade components in the future. OpenLP will run just as well on either, just as long as it supports dual screen.

  • edited April 2010

    Thank you gushie. This helps a lot.

    John

  • edited April 2010

    Hi

    I have experienced the same with slow slides.

    If pictures are large the transistion from slide to slide takes longer time (seconds on my computer). Resize your image (to a lower resolution ex. 1024x768) before creating the theme. This works for me.

    It would be really great if it was possible to have openlp doing this by itself when creating a new theme.

    Does this help you?

    Best wishes,
    Mads

  • edited April 2010

    Doing a permanent resize might not always be a good idea. What happens if your projector's resolution changes (due to getting something like a new projector)? In most cases it'll probably be fine, but you never know...

  • edited April 2010

    I have found openlp to be a bit slow (about 0.5 sec) when changing slides on songs (solid coluor background with not text fx). I have used some progams that seam to do it instantly.

     

    I dont know how OpenLP works, but could all the slides for the currenly live song be buffered in memory? I'm not to bothered about images and media tbh, but bibles, songs and custom's would br good, especially as our worship leaders flit all arround the place!

  • edited May 2010

    To Raoul:
    I cannot see that this would cause a problem (doing a permanent resize). As long as you preserve the aspect ratio of the picture you will be fine. There could just be an option when creating slide to resize the image.

    Also if you change to another projector width a different resolution and perhaps aspect-ratio like 16:9, then you might want to change your whole theme library anyways since none of the 4:3 images you have will fit - or openlp.org might be smart enough just to add borders.

    To openlp developers:
    What happens when you change verse, does openlp reread the image file from the theme or why is it so slow? (I can very easily reproduce this)

    Another solution could be to let openlp resize (while maintaing aspect ratio) the image so it fits the monitor resolution when opening the song, and use this resized image for each verse in the song.

    Best wishes,
    Mads

  • edited May 2010

    Version 2 builds the slides when needed and we have optimised the code paths to be as efficient as possible.  The delay caused by doing all the rendering up front was worse and it causes issues for churches which sing songs on the fly keeping the operator gussing what the next song is going to be.

    All the the information is in memory so there is not file access (unless memory is cached to disk by the OS, outside our control).

    Bible verses are the worst as they need extra processing to built them into slides unlike songs where it is hoped they are already split into sensible screenfulls.

    The cost is not the image but getting the text into the correct locations and to the right size.

    Feel free to come and look at the renderer code and see where it can be improved all suggestions are welcome.

  • edited March 2011

    Sorry, I know this is a very very old post. Just wanted to post my latest findings.

    I recently bought at new laptop - Core i7, 8GB ram, Windows 7 64 bit, good graphics, full hd screen etc... I would have thought it would do slide transistions in a jiffy, but it doesn't. So I tried various things to figure out what was >my< problem. 

    What helped me (besides keeping the background image at a resonable size, as discussed earlier) is also to keep the resolution of the projector/output monitor at a "low" resolution.
    For me running the output display at full hd (I know insanely high) would give very slow slide transistions for me. When I decreased the output resolution to something near 1024x768 or similar, everything went smoot. I guess if running openlp without an external monitor, it defaults the output resolution to the your primary screens resolution?

    If I just had connected my pc to a projector in the first place, instead of just playing around at home, it would have worked straight out of the box. So if someone is playing around with openlp at home, with only one screen and they are using a high screen resolution (like 1080p), I guess they will see slow transistions? (I am not sure though if openlp would run faster in a 32 bit version of Windows 7?)

    This also makes sense to me, since TRB413? above mentioned that rendering is what is causing all the delay, and rendering at a higher resolution would obviously cause more delay.

    UPDATE:
    Font size also have a huge influence on rendering time, especially with outline selected (which I always use).

    Anyone experiencing the same?

    Just my 50 cents (again),
    Mads

  • edited March 2011

    I've also noticed that the operating system you use has a definite influence. I found that Windows is almost always much slower than Linux. I've tested it out on the same hardware, and OpenLP on Linux always outperformed OpenLP on Windows, despite the fact that it was the same computer both times.

  • edited March 2011

    Outline will make a significant speed difference, since we're having to display the text twice, one slightly smaller over the top of another.

    Future versions of the qtwebkit library we use will hopefully help with this, since there are fixed CSS issues allowing us to do this more efficently. Unfortunately the qtwebkit cogs seem to run quite slowly, and these fixes are not getting to the stable releases as quickly as I hoped.

Sign In or Register to comment.